[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 --- Comment #7 from Jonathan Wakely --- (In reply to David Edelsohn from comment #5) > __has_builtin() does not mean that the builtin is inlined. It only means > that GCC recognizes the builtin. That is how __has_builtin() is documented. > In 32 bit mode, GCC emits an external reference for the builtin: 8 byte > atomic requires libatomic library, which is not linked by default (and > shouldn't be). And this is consistent with e.g. __has_builtin(__builtin_strlen). The fact that GCC recognizes the token "__builtin_strlen" doesn't mean that you don't need an extern definition of strlen for cases where the built-in isn't inlined. It's just that for the atomic built-ins the name of the built-in is the same as the name of the extern function that might be used.
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 Rohan McLure changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Rohan McLure --- David is right, I was assuming '__has_builtin' implied that the function would be inlined in without needing to be obtained from libatomic. The translation unit attached should then at least compile with no linker flags required, as if the check fails it should define a stub implementation of __atomic_store_8 (pardon the obvious syntax error in that stub). Sorry, my mistake. Yes that makes more sense.
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #5 from David Edelsohn --- Rohan, I'm sorry that this is confusing, but the issue is cockpit error. __has_builtin() does not mean that the builtin is inlined. It only means that GCC recognizes the builtin. That is how __has_builtin() is documented. In 32 bit mode, GCC emits an external reference for the builtin: 8 byte atomic requires libatomic library, which is not linked by default (and shouldn't be).
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 --- Comment #4 from Jonathan Wakely --- What are you actually trying to do here? If you're trying to provide your own definitions for the atomic built-ins then obviously you need to know platform-specific details, including whether that operation is already expanded without emitting a library call. If you're trying to do something else, maybe testing the macro __GCC_ATOMIC_LLONG_LOCK_FREE==2 can help.
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81358 --- Comment #3 from Andrew Pinski --- These builtins are always available (via libatomic if neded) so testing __has_builtin does not make sense. If you are asking why libatomic is not automatically linked then this is a dup of bug 81358.
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 --- Comment #2 from Rohan McLure --- The issue here is less that I don't have access to the symbol __atomic_store_8, it's that the preprocessor directive __has_builtin appears to false positive.
[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734 Andrew Pinski changed: What|Removed |Added Keywords|rejects-valid | --- Comment #1 from Andrew Pinski --- Link against libatomic.
