This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
- From: "amacleod at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 14 Aug 2012 22:44:53 +0000
- Subject: [Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
- Auto-submitted: auto-generated
- References: <bug-54005-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> 2012-08-14 22:44:53 UTC ---
Actually, that's the way __atomic_is_lock_free() has always been implemented
(even in 4.7).
The change is simply wrong and needs to be reverted. __atomic_is_lock_free()
*must* call the library routine of the same name if the compiler can't generate
the lock free sequence. That's the way the 2 routines were designed to
inter-operate. The current code introduces an new upgrade path bug, so its
fixing a problem in the wrong place and introducing another.
And yes, 54004 is legitimate and separate from this issue. Fixing that by
giving targets a say in what atomic alignment is will resolve this one without
any changes.