[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- I think this is also related to the discussion that followed: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02254.html
[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456 --- Comment #3 from Patrick Oppenlander --- (In reply to jos...@codesourcery.com from comment #2) > 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. What you describe is the current behaviour when using LTO. gcc happily inlines the implementations of atomic library functions for which it can't expand builtins. For context, I came across this problem while implementing atomic support on ARM Cortex-M0. Cortex-M0 doesn't support load/store-exclusive so a full suite of functions must be provided. I then built the same project targeting Cortex-M4 for which the Cortex-M0 implementations are not optimal, but should still work. However, the resultant binary used gcc provided builtins in some places and my Cortex-M0 implementations in others. I think it needs to be consistently one way or the other, or fail to build in this situation. Personally, I like the concept of being able to provide external implementations, especially when considering bare-metal embedded programming.
[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456 --- Comment #2 from 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.
[Bug middle-end/88456] __atomic_compare_exchange implementation inconsistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org Component|other |middle-end --- Comment #1 from Richard Biener --- I guess your implementation somehow gets picked up by the inliner but eventually code generation will open-code non-inlined "calls" with the internally available implementation. I _think_ that inlining your implementation is the bug. Joseph?
