This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]