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: REC: gimplify - create a temp that is set at outermost block?


On 05/19/09 11:29:57, Andrew Pinski wrote:
> On Tue, May 19, 2009 at 11:25 AM, Gary Funck <gary@intrepid.com> wrote:
> >
> > For UPC code generation, we're building an alternate
> > method of accessing thread-local data that does not depend upon
> > operating system support of the __thread qualifier.
> 
> GCC has already added generic support for the __thread qualifier which
> does not depend on the OS needing builtin support at all.

Andrew, thanks.

The only implementation that I'm aware of is described in
Ulrich Drepper's 2005 paper,
http://people.redhat.com/drepper/tls.pdf

Is the __thread feature now more universally/portably
supported?  My impression is that this feature requires
GNU/ELF linker and glibc support.  Is that correct? 

We have been using builtin __thread support for quite a
while.  It generally has worked well on most modern Linux
platforms, but we have encountered a few issues/glitches:

    * On SuSE 10/altix, we have seen overflows of the
    thread-local linker section, when compiling programs
    that declare many large TLS variables.

    * On CentOS 5/x86, we have seen programs that sometimes
    fail at 'exec' time, possibly because it can't muster
    the resources needed to start the program, or allocate
    the memory map.  Those failures have been intermittent
    with no suspicious entries in the system logs.

    * On the older SGI/Irix systems, there has been no
    __thread support at all from what I can recall.

Those limitations have motivated our need to provide
a more portable implementation of TLS variables.

thanks,
- Gary


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