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@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@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 _______________________________________________ cfe-users mailing list cfe-users@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
