https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
Bug ID: 81283 Summary: Quirks around 32-bit PowerPC built-in Atomics Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Target Milestone: --- Context: /home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc -fno-strict-aliasing -fno-tree-vrp -Wno-array-bounds -Xlinker --no-undefined -Xlinker -soname=_APP_ -nostdlib -Xlinker --no-undefined Compiler: $ /home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc -v Using built-in specs. COLLECT_GCC=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc COLLECT_LTO_WRAPPER=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/5.4.0/lto-wrapper Target: powerpc-apple-haiku Configured with: /home/kallisti5/Code/buildtools/gcc/configure --prefix=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc --target=powerpc-apple-haiku --disable-nls --disable-shared --with-system-zlib --enable-languages=c,c++ --enable-lto --enable-frame-pointer --with-sysroot=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/sysroot --disable-threads --disable-tls --disable-libatomic --disable-multilib Thread model: single gcc version 5.4.0 (GCC) We started to leverage the built-in atomics a year or two ago. When our target is powerpc, functions using 64-bit atomics result in gcc generating __atomic_fetch_add_8 calls. The GCC documention for __atomic_* doesn't mention this behaviour (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html), however the older __sync_* built-ins does (https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html): "Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." Is there a reason for the 64-bit atomic built-ins not working on powerpc? (Even if inefficently stubbed out) Is there a way to detect maximum built-in atomic width without needing a long list of architectures or gcc-centric code? Thanks! -- Alex