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.