http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot
com> 2012-06-25 23:32:04 UTC ---
On Mon, 25 Jun 2012, vincent-gcc at vinc17 dot net wrote:
> But what if a recent glibc version isn't used?
The standard describes cooperating language and library implementations,
not either on their own. glibc 2.16 is the first version with any
significant C11 support (anything beyond quick_exit / at_quick_exit); you
shouldn't expect the more library-related bits of language support to work
well without it (or another library whose maintainers have worked with the
GCC maintainers on areas requiring cooperation, such as this), or the
library support in glibc to work well without the associated compiler
support (not all yet implemented, but some parts are in 4.7, in particular
the built-in functions needed for CMPLX macros, some were in earlier, in
particular the u"" and U"" support, and more should be in 4.8).
> Would GCC still be able to compile the following code?
>
> int main (void)
> {
> #if __STDC_VERSION__ >= 201112L && ! __STDC_NO_THREADS__
> _Thread_local int i = 17;
> #endif
Such a test is not meaningful for documented incomplete support; in the
absence of claims of conformance, __STDC_VERSION__ can only be interpreted
as a statement of intent (so far as differences between standard versions
are implemented, this version has been chosen) rather than as indicating
that a particular feature is or is not present - that's simply a reality
of incremental development, partial features are documented as partial and
you can either work with the features available at a particular time,
implement the extra ones you want or wait for new versions of all relevant
components that have the bits you want. But, at some point I expect to
implement _Thread_local support and then it will work everywhere __thread
does (via the existing TLS emulation support, etc., for architectures
without hardware TLS). C11 _Thread_local is mainly a keyword alias and
adjustment of various errors to follow the exact C11 rules; C++11
thread_local is harder because of the ABI implications of TLS objects with
static constructors (and the associated interactions with dlopened
objects).
(The code you give should be rejected if __STDC_NO_THREADS__ is not
defined, because of the constraint in 6.7.1#3: "In the declaration of an
object with block scope, if the declaration specifiers include
_Thread_local, they shall also include either static or extern.".)
> Shouldn't GCC define __STDC_NO_THREADS__ to 1 by default and stdc-predef.h
> undefine it if _Thread_local is supported at the library level?
I think that just makes things unduly complicated.
