https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #7 from James Y Knight <foom at fuhm dot net> --- (In reply to Jim Wilson from comment #6) > On Thu, 2018-05-31 at 15:07 +0000, foom at fuhm dot net wrote: > > (But also, why doesn't it implement __atomic_add_fetch inline?) > > If you don't have atomic instructions, then we call an out-of-line > function that uses locks. Except as mentioned in the initial message, it doesn't emit calls for atomic loads and stores too, but it needs to so that they also participate in the locking. > If you have atomic instructions, and it is a 32/64-bit operation, then > we inline it. > > If you have atomic instructions, and it is a 8/16-bit operation, then > we call a lock free out-of-line function that uses a sequence of > instructions to implement it using 32/64-bit atomic instructions. If you're building for rv32ia, yes, you certainly know that libatomic must implement __atomic_fetch_add_1 lock-free. So, sure, you shouldn't have a correctness issue by mixing the calls. Yet even so, if you actually needed to emit a call to a known-lock-free out-of-line function, it's better to give it a different name (e.g. __sync_*) and include that in libgcc.a. Emitting a call to the __atomic_* function means you require users to link against libatomic.so, which shouldn't be required here. > And > as mentioned previously, I have an unfinished prototype patch to fix > this by emitting the sequence of instructions inline. But doing that is fine, too, and likely preferable.
