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

[John Steele Scott]

On 15/05/15 15:58, John Steele Scott wrote:
> Is there any way around this, besides hacking Clang's version of stdatomic to not do the #include_next?

<https://llvm.org/bugs/show_bug.cgi?id=22740> suggests a workaround, but then I run into another problem, because my codebase has atomics embedded in structures which are sometimes passed using pointer-to-const.

jscott at citra:/tmp$ cat atomic.c 
#undef __STDC_HOSTED__
#define __STDC_HOSTED__ 0
#include <stdatomic.h>
#undef __STDC_HOSTED__
#define __STDC_HOSTED__ 1

int f (const atomic_int *p_x)
{
  return atomic_load(p_x);
}
jscott at citra:/tmp$ clang -std=c11 -c atomic.c 
atomic.c:9:10: error: address argument to atomic operation must be a pointer to non-const _Atomic type ('const atomic_int *' (aka 'const _Atomic(int) *') invalid)
  return atomic_load(p_x);
         ^           ~~~
/usr/lib/llvm-3.6/bin/../lib/clang/3.6.1/include/stdatomic.h:134:29: note: expanded from macro 'atomic_load'
#define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
                            ^
1 error generated.


Reading <https://github.com/kcat/openal-soft/issues/3> suggests this is technically correct with respect to the standard, but since it's not very useful, the standard is likely to change, via DR459 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_459.htm>.

Cheers,

John