Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762762AbXJZWZA (ORCPT ); Fri, 26 Oct 2007 18:25:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755215AbXJZWYy (ORCPT ); Fri, 26 Oct 2007 18:24:54 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:56876 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754932AbXJZWYx (ORCPT ); Fri, 26 Oct 2007 18:24:53 -0400 Date: Fri, 26 Oct 2007 15:24:44 -0700 (PDT) From: Linus Torvalds To: Giacomo Catenazzi cc: Bart Van Assche , linux-kernel@vger.kernel.org Subject: Re: Is gcc thread-unsafe? In-Reply-To: <4722600A.4090903@cateee.net> Message-ID: References: <4722600A.4090903@cateee.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1987 Lines: 45 On Fri, 26 Oct 2007, Giacomo Catenazzi wrote: > > So we have the great opportunity to change the standard, then > gcc will change ;-) I see the smiley, but sadly, new standards take ten years or more to mature. Which means that even if the upcoming one is "perfect", things will be wrong with it, if only because people will have new usage scenarios where the standard simply isn't relevant or that it otherwise just doesn't address, and that then gets us back to the same issues somewhere else. So it would be much better if developers just didn't think the standard trumped "real and existing code and problems", and shot down the language lawyers (and don't get me wrong - it's not just in gcc, btw. We _have_ had some of the same behavior in the kernel, although I will argue that our "backwards compatibility trumps pretty much everything else" rules at least solves _some_ of the problems). Standards are just papers. Yes, they're important, but they are definitely not more important than anything else, and they are a lot _less_ important than some people seem to think. Gcc has done more for programming by being a de-facto standard and widely available, than the _paper_ standards often ever do! It's also sad that a lot of these things seem to be done in the name of optimizing code, and then in many cases it drives people *away* from using that optimizer for anything but benchmarking. In the kernel, we historically used to try for extreme optimizations, these days we spend more time tuning the optimizations _down_ because they aren't optimizations at all (ie using -Os instead of -O2), or they were buggy enough that we have to explicitly disable them (aliasing, "unit-at-a-time" etc). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/