From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5082 invoked by alias); 7 Nov 2011 14:45:23 -0000 Received: (qmail 5055 invoked by uid 22791); 7 Nov 2011 14:45:21 -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 14:44:52 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7Ein70022460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 09:44:50 -0500 Received: from [10.11.9.137] (vpn-9-137.rdu.redhat.com [10.11.9.137]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA7EilAs003186; Mon, 7 Nov 2011 09:44:48 -0500 Message-ID: <4EB7EEDF.1040103@redhat.com> Date: Mon, 07 Nov 2011 14:56: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: 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> In-Reply-To: <201111071117.pA7BHERD007071@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/msg00952.txt.bz2 >> On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote: >>> This (formally a change in the range 181027:181034) got me three >>> libstdc++ regressions for cris-elf, which has no "atomic" >>> support whatsoever (well, not the version represented in >>> "cris-elf"), so something is amiss at the bottom of the default >>> path: >> yes, I have a final pending patch which didn't make it to the branch >> before the merge. It changes the behaviour of atomic_flag on targets >> with no compare_and_swap. I *think* it will resolve your problem. >> >> I've attached the early version of the patch which you can try. Its >> missing a documentation change I was going to add tomorrow before >> submitting, but we can see if it resolves your problem. Give it a shot >> and let me know. > Sorry, no it didn't help. No additional regressions either > though, but the undef'd reference changed to two: > > Excess errors: > /tmp/atreg1/gccobj/cris-elf/libstdc++-v3/include/bits/atomic_base.h:273: undefined reference to `std::atomic_thread_fence(std::memory_order)' > /tmp/atreg1/gccobj/cris-elf/libstdc++-v3/include/bits/atomic_base.h:274: undefined reference to `__sync_lock_test_and_set_1' > collect2: error: ld returned 1 exit status > 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. bkoz: I guess what we need is a way to disable all atomic support for targets which do not have an implementable atomic_flag class? Thats why we're getting the unresolved external __sync_lock_test_and_set_1 , in order to get his far, we assume that minimal level of support... rth: __sync_lock_test_and_set_1 could be provided by libgcc if the OS has hooks in it to provide functionality... How can we tell when compiling a C++ program whether that is going to be an unresolved external or whether libgcc is going to provide it? I know you have a pending patch for libgcc support fo the __atomics, but Im unsure how we check this from the compiler I should also change it so that the compiler issues an error if atomic_thread_fence doesn't resolve to a something since that implies there is no __sync_sychronize() either, which is also minimally expected at this point. It should never become an external reference. Andrew