[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crowl at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 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.