This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 12 Dec 2018 17:37:33 +0000
- Subject: [Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
- Auto-submitted: auto-generated
- References: <bug-88456-4@http.gcc.gnu.org/bugzilla/>
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.