From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23416 invoked by alias); 7 Nov 2011 17:12:01 -0000 Received: (qmail 23400 invoked by uid 22791); 7 Nov 2011 17:11:59 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_CX 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; Mon, 07 Nov 2011 17:11:41 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7HBZUh013114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 12:11:35 -0500 Received: from [10.11.9.137] (vpn-9-137.rdu.redhat.com [10.11.9.137]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA7HBXQE021658; Mon, 7 Nov 2011 12:11:34 -0500 Message-ID: <4EB81145.9090804@redhat.com> Date: Mon, 07 Nov 2011 17:24:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Joseph S. Myers" CC: Hans-Peter Nilsson , hp@axis.com, gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, Benjamin Kosnik , Richard Henderson Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3 References: <201111071117.pA7BHERD007071@ignucius.se.axis.com> <4EB7EEDF.1040103@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-11/txt/msg01009.txt.bz2 On 11/07/2011 11:24 AM, Joseph S. Myers wrote: > On Mon, 7 Nov 2011, Andrew MacLeod wrote: > >> Actually, this target has no lock free support whatsoever? ie, no >> compare_and_swap instruction, nor an implementation of sync_lock_test_and_set >> and sync_lock_release? >> >> I think the libstdc++ standard now requires the class atomic_flag to be lock >> free in order to conform (n3242 29.7.2) >> >> So I guess this is the situation which all the atomic tests are not even >> suppose to be run since they aren't supported. My guess is that in the >> previous releases the c++ header files probably provided a locked >> implementation of test_and_set, and so the tests would run. > For bare-metal targets there should maybe be an option to presume there is > just one thread and map all atomic operations to dumb non-atomic versions, > which is perfectly valid in such a case. But that's a new feature; we > didn't have it for __sync_* either. > Hmm. actually, there is a proposed option flag which I noticed never got implemented when I was looking back through stuff on the weekend: http://gcc.gnu.org/wiki/Atomic/GCCMM/ExecutiveSummary Exposure to the normal users can be provided through something along the lines of: -fmemory-model=c++0x - Disable data races as per architectural requirements. -fmemory-model=safe - Disable all data race introductions. (enforce all 4 internal restrictions.) -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) we could do that with -fmemory-model=single and it would be pretty natural...and easy. The just fall back to a load for test and set and then atomic_flag would work fine. Such targets would make that the default, and since the option isn't set to C++11, it wouldn't have to be conforming anyway. Mostly I think it the option wasn't implemented because we never finished up with the load/store data race work. We continue to count on __sync_test_and_set and sync_lock_release for targets without a compare and swap operation to provide the atomic_flag implementation. As for all the rest of the atomics, it defined right now that if the compiler cannot generate lock free instructions, it generates a call to the external library. I would suggest on such a limited target that they build the library, and it would provide locked routines for all the rest of the external calls. The library could also be configured for single thread operation which would then just provide the operation without locks if desired. A buildable library is forthcoming in the next few months. Andrew