From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 856 invoked by alias); 25 Mar 2011 15:20:22 -0000 Received: (qmail 841 invoked by uid 22791); 25 Mar 2011 15:20:21 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Mar 2011 15:20:14 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id B609091222; Fri, 25 Mar 2011 16:20:12 +0100 (CET) Date: Fri, 25 Mar 2011 15:27:00 -0000 From: Michael Matz To: Aldy Hernandez Cc: Richard Guenther , Andrew MacLeod , "Joseph S. Myers" , Richard Henderson , gcc-patches , Jeff Law Subject: Re: [cxx-mem-model] disallow load data races (1 of some) In-Reply-To: <4D8C9140.3020506@redhat.com> Message-ID: References: <4D8B8051.2030307@redhat.com> <4D8BA278.8000300@redhat.com> <4D8BB82F.3060901@redhat.com> <4D8BDA6F.2090304@redhat.com> <4D8C9140.3020506@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg01749.txt.bz2 Hi, On Fri, 25 Mar 2011, Aldy Hernandez wrote: > > But speculative loads are never a problem. So I'd like to avoid > > cluttering GCC code with stuff to avoid them. I honestly don't care > > about diagnostic tools that fail to see if a value read is used or > > not. > > Frankly, I agree. The standard (and the aforementioned paper) says that > load data races are disallowed... > > "If we had hypothetical hardware (or a virtual machine) that aborted the > program when a race was detected, compilers would not be allowed to introduce > potentially racing loads... even if the result of the load were unused would > change the semantics of the program. Although such environments are not > commonplace, they have certainly been proposed, and may well turn out to be > very useful." > > ...but, if there's no hardware for it, I see no need for spending time on > this. Even if there was such (IMO useless) hardware, or somebody would waste his time in writing such (equally useless) virtual machine that can detect fabricated problems somebody invented for some standard that never are going to be problems in the real world, we shouldn't feel obliged to uglify GCC for that. (OTOH my opinion about the new c++ memory model is known ;) ) Ciao, Michael.