Bug 81283

Summary: Quirks around 32-bit PowerPC built-in Atomics
Product: gcc Reporter: Alexander von Gluck <kallisti5>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: normal CC: segher
Priority: P3    
Version: 5.4.0   
Target Milestone: ---   
Host: Target: powerpc-*-*
Build: Known to work:
Known to fail: Last reconfirmed:

Description Alexander von Gluck 2017-07-03 04:15:48 UTC
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
Comment 1 Alexander von Gluck 2017-07-03 04:17:05 UTC
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);
}
Comment 2 Andrew Pinski 2017-07-03 04:19:33 UTC
>Is there a reason for the 64-bit atomic built-ins not working on powerpc?

Yes because 32bit PowerPC does not have 64bit atomics.
Comment 3 Alexander von Gluck 2017-07-03 04:21:53 UTC
I may be misguided, but wouldn't it be possible to handle these in software with some sync's and some wrapper code?
Comment 4 Alexander von Gluck 2017-07-03 04:23:40 UTC
I mean... I know we have 32-bit x86 builds using that exact same code :-)
Comment 5 Andreas Schwab 2017-07-03 07:05:38 UTC
Link against libatomic.
Comment 6 Alexander von Gluck 2018-07-16 21:31:18 UTC
Sorry for the late reply on this one.  I'm pretty sure I did this and it worked :-)