https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69404
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
The GCC manual says the __atomic builtins are meant to be compatible with those
described in the Intel Itanium Processor-specific Application Binary Interface,
section 7.4. Both the ABI and the GCC manual describe the builtins to operate
on objects of some /type/. For example, __atomic_load is described like so:
__atomic_load (type *ptr, type *ret, int memorder)
implying that ptr and ret should be compatible. (The ABI doesn't describe
__atomic_load but it does describe many of the __atomic builtins.)
GCC rejects the test cases when the __atomic builtins are replaced with the
corresponding C11 atomic generic functions defined in <stdatomic.h>, but only
because these are implemented as macros involving conversions that detect the
incompatibility. The C11 generics that don't do such conversions are just as
impotent at detecting incompatibilities as the corresponding builtins. For
example, GCC doesn't diagnose the program below (both Clang and Intel CC do
issue the expected diagnostic -- ICC when the _Atomic keyword is removed as it
doesn't seem to understand it yet).
$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
z.c
#include <stdatomic.h>
int* foo (void (*p)(void))
{
int* _Atomic q;
atomic_init (&q, 0);
atomic_fetch_add (&q, p);
return q;
}
I certainly agree that GCC can define its own extensions any way it sees fit.
But I can think of no use for this "extension" except to make it easier to
accidentally write incorrect code.
Incidentally, I came across this problem while testing a patch for bug 64843
(and improving the documentation of the builtins in the GCC manual op resolve
bug 52291).
