This is the mail archive of the gcc@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]

Re: Thread-local storage on IA64 in ILP32 mode


> Suppose gcc is build with tls support, but the surrounding system
> doesn't have it.  Unless the user writes __thread, no one's the 
> wiser.  If they do write __thread, then they get what they deserve.

An error message from the compiler is rather nicer than silent
miscompilation.

And when the sysadmin installing GCC runs "make check", they should not
see unexpected failure; they might reasonably think the compiler is
broken.

The failure mode is much better the other way.  If, on a system with TLS
support, the compiler is built so that TLS support is disabled there are
two scenarios:

1) The user doesn't try to use TLS, in which case the fact it is
disabled in the compiler doesn't affect them.

2) They do try it.  They get an error message, and know that either the
system or the compiler is broken.

At present, most (all?) TLS-enabled systems are GNU/Linux systems, and
on those systems most users are getting pre-built compilers built by
distributors who presumably know how to turn on TLS.

I think that if we cannot fully autoconf for TLS correctly, we should
disable it except on systems where (a) we have the assembler support,
and (b) the configuration explicitly enables it.  

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com


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