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
Here is some context on our wrapper for the atomic call generating the __atomic_fetch_add_8 references. static __inline__ void atomic_set64(int64* value, int64 newValue) { __atomic_store_n(value, newValue, __ATOMIC_RELEASE); }
>Is there a reason for the 64-bit atomic built-ins not working on powerpc? Yes because 32bit PowerPC does not have 64bit atomics.
I may be misguided, but wouldn't it be possible to handle these in software with some sync's and some wrapper code?
I mean... I know we have 32-bit x86 builds using that exact same code :-)
Link against libatomic.
Sorry for the late reply on this one. I'm pretty sure I did this and it worked :-)