__thread

__thread

[Tamás Gergely]

Hi!

I'm trying to compile glibc-2.2.5 for arm-elf with both gcc-3.2 and the 
latest snapshot (currently gcc-20030310). While it was a successful attempt 
with gcc-3.2, compiling with the snapshot I got the following error:

In file included from ../include/pthread.h:1,
                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
                  from ../sysdeps/generic/ldsodefs.h:34,
                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                  from ../sysdeps/unix/sysv/linux/init-first.c:32:
../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
"__thread"

The line in ../linuxthreads/sysdeps/pthread/pthread.h was:

extern int pthread_create (pthread_t *__restrict __thread,

I made a check: preprocessed init-first.c with both compilers (both 
preprocessed file contained the line above) and then compiled the results 
with the compilers exchanged. The result was the same: gcc-3.2 passed (on 
snapshot-preprocessed file) and the snapshot failed (on gcc-3.2-preprocessed 
file).

As I read some former mails in the archive, I found that gcc-3.2 should have 
failed with __thread and the snapshot should have passed.

I also found that there is something done with __thread in the gcc/fixinc 
directory of the snapshot, but this thing is missing from the gcc-3.2.

My questions are:

- What is the purpose of the fixinc directory?
- Could the things in the fixinc "correct" the glibc headers, and if they 
could, how?
- Is that a bug in gcc-3.2 that it accepts __thread? (By the way, it accepts 
anything at that place.)
- How can I get the snapshot to compile glibc?

Thanks:

gertom
-- 
**************************************************************************
* Gergely TamĂĄs                                    e-mail:gertom@rgai.hu *
**************************************************************************

Re: __thread

[Fergus Henderson]

On 14-Mar-2003, Tam?s Gergely <gertom@rgai.hu> wrote:
> In file included from ../include/pthread.h:1,
>                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
>                  from ../sysdeps/generic/ldsodefs.h:34,
>                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
>                  from ../sysdeps/unix/sysv/linux/init-first.c:32:
> ../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
> "__thread"

Ouch.  According to the C standard, the section of the namespace
starting with "__" is reserved for use by the implementation, but the
implementation consists of two parts, a compiler and a library,
and in this case there is a name clash -- GCC's use of "__thread"
clashes with glibc's use of it.

> The line in ../linuxthreads/sysdeps/pthread/pthread.h was:
> 
> extern int pthread_create (pthread_t *__restrict __thread,

In GCC 3.2, "__thread" is just an ordinary identifier,
so this gets parsed as a parameter name.  That is what
the glibc source intended.

In current CVS GCC, "__thread" is now a keyword, and as such it is not
allowed to appear here.  That's why CVS GCC reports a syntax error.

> - Is that a bug in gcc-3.2 that it accepts __thread? (By the way, it 
> accepts anything at that place.)

No.  In 3.2, "__thread" is just an ordinary identifier (in the
implementation name space, since it starts with "__").  Since
it is used as a parameter name in a function declaration,
any other identifier would do just as well.

> - What is the purpose of the fixinc directory?

To fix problems like this, if they occur in already-installed
header files.

> - Could the things in the fixinc "correct" the glibc headers, and if they 
> could, how?

In theory, yes, although I don't know if they do currently, and I'm not sure
if fixinc is run on Linux anyway.

> - How can I get the snapshot to compile glibc?

Change the glibc sources to use a different identifier, e.g.
"__thread_param", instead of "__thread".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: __thread

[Andreas Schwab]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

|> > - How can I get the snapshot to compile glibc?
|> 
|> Change the glibc sources to use a different identifier, e.g.
|> "__thread_param", instead of "__thread".

That has already been fixed in the current glibc release.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

glibc problems with snapshot

[Tamás Gergely]

Andreas Schwab wrote:
> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> 
> |> > - How can I get the snapshot to compile glibc?
> |> 
> |> Change the glibc sources to use a different identifier, e.g.
> |> "__thread_param", instead of "__thread".
> 
> That has already been fixed in the current glibc release.
> 
> Andreas.
> 

Thanks!

I have another problem, now with glibc-2.3.2: the gcc snapshot fails:

In file included from ../linuxthreads/sysdeps/pthread/sigaction.c:53,
                  from ../linuxthreads/sysdeps/pthread/sigaction.c:53,
                  from ../linuxthreads/sysdeps/pthread/sigaction.c:29:
../sysdeps/unix/sysv/linux/arm/sigaction.c: In function `__libc_sigaction':
../sysdeps/unix/sysv/linux/arm/sigaction.c:100: error: asm-specifier for 
variable `_a1' conflicts with asm clobber list
../sysdeps/unix/sysv/linux/arm/sigaction.c:139: error: asm-specifier for 
variable `_a1' conflicts with asm clobber list

The preprocessed input is:

result = ({ unsigned int _sys_result = ({ unsigned int _sys_result; { 
register int _a1 asm ("a1"); register int _a4 asm ("a4") = (int) (64 / 8); 
register int _a3 asm ("a3") = (int) (oact ? (&koact) : ((void *)0)); 
register int _a2 asm ("a2") = (int) (act ? (&kact) : ((void *)0)); _a1 = 
(int) (sig); asm volatile ("swi	%1	@ syscall " "rt_sigaction" : "=r" (_a1) : 
"i" (((0x900000 +174))) , "r" (_a1), "r" (_a2), "r" (_a3), "r" (_a4) : "a1", 
"memory"); _sys_result = _a1; } (int) _sys_result; }); if (__builtin_expect 
(((unsigned int) (_sys_result) >= 0xfffff001u), 0)) { ((*__errno_location 
()) = ((-(_sys_result)))); _sys_result = (unsigned int) -1; } (int) 
_sys_result; });

I found the error message in gcc-20030310/gcc/stmt.c. It's comment is:

/* Conflicts between asm-declared register variables and the clobber
    list are not allowed.  */

gcc-3.2 does not have this check, and it passes this source. Could anyone 
tell me how to correct the problem (or explain what is the problem exactly)?

gertom

-- 
**************************************************************************
* Gergely TamĂĄs                                    e-mail:gertom@rgai.hu *
* ICQ:104783919                                    http://gertom.rgai.hu *
**************************************************************************

Re: __thread

[Joe Buck]

On Thu, Mar 20, 2003 at 01:55:15PM -0800, Richard Henderson wrote:
> On Thu, Mar 20, 2003 at 06:37:28PM +0000, Jonathan Larmour wrote:
> > May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 
> 
> No.  Not the least of reasons being that we're implementing a
> multi-vendor extension.

Perhaps we need some mechanism for GCC, glibc, Linux kernel, and BSD kernel
people to keep each other aware when new __xxx identifiers are to be added.
Other OS distributors could participate as well, but the idea would be to
have advance warning before new breakage occurs.

Re: __thread

[Richard Henderson]

On Fri, Mar 21, 2003 at 12:20:05AM +0000, Jonathan Larmour wrote:
> Ugh. After some searching I see this is the TLS ABI, originating from the 
> Itanium psABI.

The keyword pre-dates this, though the specific implementation
of the runtime is directly derived from this.


r~

Re: __thread

[Fergus Henderson]

On 20-Mar-2003, Jonathan Larmour <jifl@eCosCentric.com> wrote:
> >On 14-Mar-2003, Tam?s Gergely <gertom at rgai dot hu> wrote:
> >>In file included from ../include/pthread.h:1,
> >>                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
> >>                 from ../sysdeps/generic/ldsodefs.h:34,
> >>                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
> >>                 from ../sysdeps/unix/sysv/linux/init-first.c:32:
> >>../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
> >>"__thread"
> >
> >Ouch.  According to the C standard, the section of the namespace
> >starting with "__" is reserved for use by the implementation, but the
> >implementation consists of two parts, a compiler and a library,
> >and in this case there is a name clash -- GCC's use of "__thread"
> >clashes with glibc's use of it.
> 
> This could easily have been foreseen. eCos has been bitten by this too, as 
> well as no doubt many other OS's, kernels and runtime systems (although 
> most don't know it yet). We can fix what we've got now, but now we'll be 
> annoyed by people who can't get older (than today) versions of the sources 
> to compile with newer GCC.
> 
> It's pretty obvious that this type of identifier would relate closely to 
> the operation of an OS and would be likely to appear there, and GCC should 
> not just assume that it can use any old identifier just because it sticks 
> "__" in front of it, and it's up to everyone else to deal with it.
> 
> May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 
> Then there's a hope of avoiding clashes between OS's and compilers. That 
> would seem the most professional approach.

When GCC adds new identifiers to the implementation namespace, these
symbols are usually intended for use by users.  For example, they may be
new keywords or new built-in functions.  In contrast, identifiers in the
implementation namespace which are defined by the OS or C library are
usually intended only for internal use by the OS or C library, not for
use by users -- otherwise they should be given a non-"__"-prefixed name.
There are some exceptions to this (e.g. _POSIX_C_SOURCE and similar),
but it does seem to be the general rule.

Using a longer prefix such as "__gcc_" rather than "__" is probably
undesirable in names intended for use by users.  Given this, wouldn't
it make more sense for the OS and C library to use such prefixes, rather
than GCC?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: __thread

[Jonathan Larmour]

Richard Henderson wrote:
> On Thu, Mar 20, 2003 at 06:37:28PM +0000, Jonathan Larmour wrote:
> 
>>May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 
> 
> 
> No.  Not the least of reasons being that we're implementing a
> multi-vendor extension.

Ugh. After some searching I see this is the TLS ABI, originating from the 
Itanium psABI. So presumably Intel happened to choose __thread and 
everyone else is now lumbered. Sigh. Courtesy of google I've seen plenty 
of free projects have already had to jump through hoops because of this 
poor choice. It's not even descriptive!

Oh well.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: __thread

[Richard Henderson]

On Thu, Mar 20, 2003 at 06:37:28PM +0000, Jonathan Larmour wrote:
> May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 

No.  Not the least of reasons being that we're implementing a
multi-vendor extension.


r~

Re: __thread

[Jonathan Larmour]

> On 14-Mar-2003, Tam?s Gergely <gertom at rgai dot hu> wrote:
>> In file included from ../include/pthread.h:1,
>>                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
>>                  from ../sysdeps/generic/ldsodefs.h:34,
>>                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
>>                  from ../sysdeps/unix/sysv/linux/init-first.c:32:
>> ../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
>> "__thread"
> 
> Ouch.  According to the C standard, the section of the namespace
> starting with "__" is reserved for use by the implementation, but the
> implementation consists of two parts, a compiler and a library,
> and in this case there is a name clash -- GCC's use of "__thread"
> clashes with glibc's use of it.

This could easily have been foreseen. eCos has been bitten by this too, as 
well as no doubt many other OS's, kernels and runtime systems (although 
most don't know it yet). We can fix what we've got now, but now we'll be 
annoyed by people who can't get older (than today) versions of the sources 
to compile with newer GCC.

It's pretty obvious that this type of identifier would relate closely to 
the operation of an OS and would be likely to appear there, and GCC should 
not just assume that it can use any old identifier just because it sticks 
"__" in front of it, and it's up to everyone else to deal with it.

May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 
Then there's a hope of avoiding clashes between OS's and compilers. That 
would seem the most professional approach.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine