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.
