[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
If the implementation were not in this source file at all and no LTO were 
used, it would be unambiguous that such an out-of-line implementation 
would not be used when GCC knows how to expand the relevant atomic 
operation inline - GCC would have to expand it inline, regardless of 
optimization level, because it couldn't rely on such an out-of-line 
implementation being linked in at all.

Thus, I'd expect GCC not to inline a user-provided implementation either, 
in the case where it knows how to expand the call through appropriate insn 
patterns.  It's not clear such inlining is a bug, however; if you provide 
your own implementations of such libgcc/libatomic functions and they don't 
have the required semantics, you're well into undefined behavior.

If the call is one GCC can't expand on its own (atomic operations on large 
objects needing locks, architecture lacks required atomic operation 
instructions, etc.), it would be reasonable for GCC to inline a definition 
to which it would otherwise generate an out-of-line call.