I am under the impression that (at least GCC) compilers will not emit intrinsic calls if they are guaranteed to be available on the target.
This means libatomic needs to: - Optimize: we can runtime detect, which emitted code cannot do. Note that this means providing this libatomic will cause us to stop noticing 64-bit atomics used when compiling for -march=i486, our default for i386. We will stop upgrading those to -march=i586 and users will see a performance penalty. - Provide the fallback code And that it isn't necessary for libatomic to: - Attempt to cause the compiler to emit the intrinsic Which should make this code a lot simpler. --- +#define LOCK_FREE_ACTION(type) \ + return atomic_compare_exchange_strong_explicit( \ + (_Atomic(type) *)ptr, (type *)expected, *(type *)desired, success, \ + failure) + LOCK_FREE_CASES(); +#undef LOCK_FREE_ACTION This feels a bit offensive... Mentally I am reading this as "I don't believe the compiler will optimize out some scenarios in cleaner code with static inline, so forcing the optimization to happen via C preprocessor". I wonder if it's really true. The macros seem overly complicated to avoid generics, I don't think pre-C11 is a concern for us. I wonder if it can be simplified.
