Re: Can we assume __thread support?

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 15 Oct 2015, Florian Weimer wrote:

> We have this:
> 
> if test "$libc_cv_gcc___thread" = no; then
>   AC_MSG_ERROR([support for the __thread keyword is required])
> fi

As a general principle, what do people think of removing such configure 
tests that exist only to produce errors, if we expect that versions 
lacking support would also fail to pass the tests of minimum GCC / 
binutils versions?  There are a *lot* of such configure tests; removing 
them is only a minor cleanup (precisely because they don't condition 
anything beyond an error), but I think such tests are generally pointless.  
(Cases where current tools might plausibly fail such a test should be kept 
- that's for exceptional cases such as the test for a compiler defaulting 
to -march=i386, where we're testing for a bad configuration rather than a 
bad version.)

Even if GCC lacked TLS support - and I don't think any supported 
architectures have any GCC versions that would pass the global version 
test but lack TLS support for that architecture - that configure test 
wouldn't help (because of TLS emulation, which doesn't suffice for glibc).  
(If we did have such an architecture-specific issue, an 
architecture-specific test for it could be added anyway.)

> The question is whether this is just a syntactic thing, or if we can
> assume that __thread support in binutils works.  We also have test cases
> for __thread-related things, and I can't see that they are conditional
> on anything or XFAILed.

We can assume __thread support in binutils works.

-- 
Joseph S. Myers
joseph@codesourcery.com