GCC 4.8.1 provides a -std=c11 option that defines __STDC_VERSION__ >= 201112L and does not define __STDC_NO_ATOMICS__, hence is required to provide stdatomic.h. This requirement is not met. This ticket is closely related to 53769 but I am not reporting the fact that the macros aren't defined, but rather the missing header. > cat test-c11-atomics.c #if __STDC_VERSION__ >= 201112L # ifdef __STDC_NO_ATOMICS__ # error Your C11 compiler is not required to provide stdatomic.h # else # include <stdatomic.h> # endif #else # error Your C compiler isn't providing C11. #endif int main(int argc, char * argv[]) { return 0; } > gcc-mp-4.8 -g -Wall -std=c11 test-c11-atomics.c test-c11-atomics.c:4:23: fatal error: stdatomic.h: No such file or directory #include <stdatomic.h> ^ compilation terminated. > gcc-mp-4.8 -v Using built-in specs. COLLECT_GCC=gcc-mp-4.8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_0' Thread model: posix gcc version 4.8.1 (MacPorts gcc48 4.8.1_0) > uname -a Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
I don't know whether Andrew intends stdatomic.h to go in GCC or glibc, but in any case I consider this a duplicate of bug 53769, which in turn I don't really consider a useful bug report at all (incompleteness of the implementation of an option documented in the manual as incomplete should not be considered a bug).
If GCC doesn't support C11, it should not claim to support C11 via __STDC_VERSION__. The C11 standard definition isn't a recommendation from which implementers can pick and choose based upon their priorities. Documentation an implementations failure to comply with a standard does not absolve an implementation from lying about its features with ISO standard macros. The macro is part of the standard; the documentation is not. In any case, there is an absolutely trivial way for GCC to satisfy the C11 standard with respect to stdatomic.h, and it involves __STDC_NO_ATOMICS__. The failure to define this macro or to provide stdatomic.h make GCC non-compliant with C11, in which case __STDC_VERSION__ is defined improperly.
Noone disputes it's not conforming. The point is the support is incomplete. It's known to be incomplete. It's documented as incomplete. Reporting a bug to say it's incomplete doesn't serve any useful purpose, it will be complete when it's completed.
__STDC_VERSION__ describes *intent* of command-line options (as regards differences between standard versions, to the extent that those are implemented). This is the same principle that has been documented for __STDC__ since at least GCC 2.0. "Sometimes people say that defining @code{__STDC__} in a compiler that does not completely conform to the ANSI C standard somehow violates the standard. This is illogical. The standard is a standard for compilers that are supposed to conform. It says nothing about what any other compilers should do. Whatever the ANSI C standard says is relevant to the design of plain @samp{gcc} without @samp{-ansi} only for pragmatic reasons, not as a requirement." (quoted from the GCC 2.0 manual). As a pragmatic matter, it's useful for users of standards modes that are incomplete to be able to tell which of those modes is in use, and __STDC_VERSION__ is the natural macro to define to distinguish between them. gcc -std=c11 is a compiler explicitly claimed not to conform.
Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ in GCC so I can submit a patch? I'd rather solve the problem and take 1-2 steps forward towards C11 compliance rather than debate the philosophical aspects of the problem.
Created attachment 30568 [details] patch to define macros indicating missing C11 support If GCC defines __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__, it is no longer non-compliant w.r.t. C11 to not provide stdatomic.h and threads.h. This would resolve bugs 53769 and 58016, albeit in a trivial way. I will not be surprised at all if this patch is rejected, if for no other reason than my institution has not signed a contributor agreement with FSF (they almost certainly will if I ask). My goal is to inspire someone else to do it properly since it seems trivial and arguably necessary.
__STDC_NO_THREADS__ is defined in glibc's stdc-predef.h because it describes combination compiler and library properties. The correct fix for atomics for 4.9 will be to implement them - see Andrew MacLeod's patches and recent discussion on gcc-patches - and the state of C11 in 4.8 is what it is and 4.8 is subject to normal release branch rules (regression and documentation fixes only, generally).
My patch was w.r.t. the trunk as of earlier today, not 4.8 but that's fine. I just subscribed to various GCC lists to track these developments. I'll apply my patch locally so that I can use 4.8.1 and get the desired behavior.