From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21263 invoked by alias); 7 Nov 2011 18:08:52 -0000 Received: (qmail 21247 invoked by uid 22791); 7 Nov 2011 18:08:51 -0000 X-SWARE-Spam-Status: No, hits=-6.8 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 18:08:36 +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 pA7I8SIk018093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 13:08:28 -0500 Received: from [10.11.9.137] (vpn-9-137.rdu.redhat.com [10.11.9.137]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA7I8Q72002165; Mon, 7 Nov 2011 13:08:27 -0500 Message-ID: <4EB81E9A.9080401@redhat.com> Date: Mon, 07 Nov 2011 18:27: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: Hans-Peter Nilsson CC: joseph@codesourcery.com, hp@axis.com, gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, bkoz@redhat.com, rth@redhat.com Subject: Re: cxx-mem-model merge [6 of 9] - libstdc++-v3 References: <201111071732.pA7HW2KR017052@ignucius.se.axis.com> In-Reply-To: <201111071732.pA7HW2KR017052@ignucius.se.axis.com> 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/msg01025.txt.bz2 On 11/07/2011 12:32 PM, Hans-Peter Nilsson wrote: >> From: "Joseph S. Myers" >> Date: Mon, 7 Nov 2011 17:24:04 +0100 >> 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. > It'd not be a new feature, that's apparently how it worked until > it broke now ...unless you mean something different. > Libstdc++-v3 use to supply a locked version of class atomic_flag (atomic_0.h implemented locked classes) if there were no lock free routines (_GLIBCXX_ATOMIC_BUILTINS_1 was not set to true in configuration): /// 29.2 Lock-free Property #if defined(_GLIBCXX_ATOMIC_BUILTINS_1) && defined(_GLIBCXX_ATOMIC_BUILTINS_2) \ && defined(_GLIBCXX_ATOMIC_BUILTINS_4) && defined(_GLIBCXX_ATOMIC_BUILTINS_8) # define _GLIBCXX_ATOMIC_PROPERTY 2 # define _GLIBCXX_ATOMIC_NAMESPACE __atomic2 #elif defined(_GLIBCXX_ATOMIC_BUILTINS_1) # define _GLIBCXX_ATOMIC_PROPERTY 1 # define _GLIBCXX_ATOMIC_NAMESPACE __atomic1 #else # define _GLIBCXX_ATOMIC_PROPERTY 0 # define _GLIBCXX_ATOMIC_NAMESPACE __atomic0 #endif This meant it would compile and run fine... That is no longer standard compliant, so we cant fall back to that any more. This is the first time we've had to face not being able to supply atomic_flag, so we need to decide what to do. So, what DO we do if there is no basic level of atomic support... I think it is reasonable to have __sync_lock_test_and_set() and __sync_lock_release() perform simple loads and stores if we can decide how best to communicate to the expanders that we only ever operating in a single threaded environment. the as-yet unimplemented -fmemory-model flag seems like the best bet unless there is something else already being set. Another option would be to have the libstdc++ header files resort to a simple load and store rather than calling a __sync routine when they know its not present. Then we aren't tainting the compiler with this arguably offbeat requirement. Andrew