From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18978 invoked by alias); 14 Aug 2012 03:52:50 -0000 Received: (qmail 18968 invoked by uid 22791); 14 Aug 2012 03:52:49 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Aug 2012 03:52:31 +0000 From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free Date: Tue, 14 Aug 2012 03:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg00809.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 Hans-Peter Nilsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |crowl at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson 2012-08-14 03:52:07 UTC --- (In reply to comment #4) > A GCC port is incorrect if it is issuing any kind of lock. GCC is only allowed > to issue a lock free sequence of some sort. If a lock is required, then a call > to libatomic must be made. > > So if there is a type which is sometimes lock free and sometimes not due to > alignment or anything else, __atomic_always_lock_free should return FALSE for > that type. Yes... > I think your current problem is that the infrastructure change for > __atomic_always_lock_free to handle alignment issues is not present yet. So it > erroneously says TRUE for this type when in fact it shouldn't. This PR is about the libstdc++ library is_lock_free function using the *per-object* builtin query when it should use the *per-type* query as per the referenced discussion. And that's been corrected. It's separate to my other target woes; an incidental observation. I agree the function has a name intuitively leading to thinking it should be per-object, but it isn't. > Its important that the libstdc++ routines call the __atomic_is_lock_free() so > that the answer can be determined at runtime if libatomic is utilized for any > atomic sequences. Maybe elsewhere, but not this particular code. If your argument is that is_lock_free should be per-object, then you'll have to argue with the standard-guys; I'm just quoting the reference above. > __atomic_always_lock_free() is *always* resolved to a 1 or a 0 at compile time. > The compiler is only capable of answering the question, "Does the compiler > always generate a lock free sequence". Which is exactly the kind of answer sought here. Is the n2992 reference incorrect or am I (and bkoz) misinterpreting it? Are things about to change again standard-wise? Let's try and ask mr. Crowl.