[cfe-users] Clang tries to use GCC's stdatomic.h, and fails.
John Steele Scott
toojays at toojays.net
Thu May 14 23:28:20 PDT 2015
Consider the following source:
jscott at citra:/tmp$ cat /tmp/atomic.c
#include <stdatomic.h>
int f (atomic_int *p_x)
{
return atomic_load(p_x);
}
On my system, Clang 3.6.1 fails to compile this, because it attempts to use GCC 5's stdatomic.h, which contains stuff it doesn't understand. [GCC 4.9's stdatomic.h fails similarly.]
jscott at citra:/tmp$ clang -std=c11 -c atomic.c
atomic.c:5:10: error: use of undeclared identifier '__auto_type'
return atomic_load(p_x);
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:142:27: note: expanded from macro 'atomic_load'
#define atomic_load(PTR) atomic_load_explicit (PTR, __ATOMIC_SEQ_CST)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:136:5: note: expanded from macro 'atomic_load_explicit'
__auto_type __atomic_load_ptr = (PTR); \
^
atomic.c:5:10: error: use of undeclared identifier '__atomic_load_ptr'
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:142:27: note: expanded from macro 'atomic_load'
#define atomic_load(PTR) atomic_load_explicit (PTR, __ATOMIC_SEQ_CST)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:137:18: note: expanded from macro 'atomic_load_explicit'
__typeof__ (*__atomic_load_ptr) __atomic_load_tmp; \
^
atomic.c:5:10: error: use of undeclared identifier '__atomic_load_ptr'; did you mean '__atomic_load_tmp'?
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:142:27: note: expanded from macro 'atomic_load'
#define atomic_load(PTR) atomic_load_explicit (PTR, __ATOMIC_SEQ_CST)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:138:20: note: expanded from macro 'atomic_load_explicit'
__atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (MO)); \
^
atomic.c:5:10: note: '__atomic_load_tmp' declared here
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:142:27: note: expanded from macro 'atomic_load'
#define atomic_load(PTR) atomic_load_explicit (PTR, __ATOMIC_SEQ_CST)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:137:37: note: expanded from macro 'atomic_load_explicit'
__typeof__ (*__atomic_load_ptr) __atomic_load_tmp; \
^
atomic.c:5:10: error: returning 'void' from a function with incompatible result type 'int'
return atomic_load(p_x);
^~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:142:27: note: expanded from macro 'atomic_load'
#define atomic_load(PTR) atomic_load_explicit (PTR, __ATOMIC_SEQ_CST)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.1.0/include/stdatomic.h:134:3: note: expanded from macro 'atomic_load_explicit'
__extension__ \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.
It looks like Clang has its own stdatomic.h at /usr/lib/llvm-3.6/lib/clang/3.6.1/include/stdatomic.h, but it defers to the GCC version because of this:
/* If we're hosted, fall back to the system's stdatomic.h. FreeBSD, for
* example, already has a Clang-compatible stdatomic.h header.
*/
#if __STDC_HOSTED__ && __has_include_next(<stdatomic.h>)
# include_next <stdatomic.h>
#else
...
Is there any way around this, besides hacking Clang's version of stdatomic to not do the #include_next?
Does Clang have an equivalent of __auto_type that I could try and use to get out of this?
e.g.
#define __auto_type __clangs_version_of_auto_type
#include <stdatomic.h>
?
Cheers,
John
More information about the cfe-users
mailing list