[cfe-users] Clang tries to use GCC's stdatomic.h, and fails.

[John Steele Scott]

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