[Bug plugins/81283] New: Quirks around 32-bit PowerPC built-in Atomics

[kallisti5 at unixzen dot com]

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