From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4706 invoked by alias); 19 Aug 2011 08:58:29 -0000 Received: (qmail 4686 invoked by uid 22791); 19 Aug 2011 08:58:28 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Aug 2011 08:58:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7J8w1P0029968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 19 Aug 2011 04:58:01 -0400 Received: from [10.36.6.235] (vpn1-6-235.ams2.redhat.com [10.36.6.235]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7J8vxL7020298; Fri, 19 Aug 2011 04:58:00 -0400 Subject: Re: [cxx-mem-model] Atomic C++ header file changes From: Torvald Riegel To: Andrew MacLeod Cc: gcc-patches In-Reply-To: <4E4BE0BE.8000901@redhat.com> References: <4E4BE0BE.8000901@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 Aug 2011 10:17:00 -0000 Message-ID: <1313744278.3533.1869.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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-08/txt/msg01553.txt.bz2 On Wed, 2011-08-17 at 11:39 -0400, Andrew MacLeod wrote: > Turns out, C++ will allow you to specify the memory model as a variable > of type enum memory_order... WTF? I would expect that to be pretty > uncommon, and in order to get that right, we'd need a switch statement > and call the appropriate __sync_mem* routine with the appropriate > constant parameter. > > That would be quite ugly, and you get what you deserve if you do that. > I changed the builtins so that if you dont specify a compile time > constant in the memory model parameter, it will simply default to > __SYNC_MEM_SEQ_CST, which will always be safe. That is standard > compliant (verified), and if anyone is really unhappy about it, then the > c++ headers can be really uglified by adding a bunch of switch > statements to handle this twisted case. IMHO this behavior should be documented so that users will be aware of it, and it would be best if this would raise a warning. Note that I also cannot see any reason why a programmer might want to make barriers runtime-configurable, but silently adding overhead (perhaps the parameter was supposed to be a constant, but wasn't?) can lead to more confusion than necessary. Torvald