public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* __thread
@ 2003-03-14 16:25 Tamás Gergely
  2003-03-14 16:50 ` __thread Fergus Henderson
  0 siblings, 1 reply; 4+ messages in thread
From: Tamás Gergely @ 2003-03-14 16:25 UTC (permalink / raw)
  To: gcc-help, gcc; +Cc: Daniel Jacobowitz, mohamed.abbas

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 *
**************************************************************************

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: __thread
  2003-03-14 16:25 __thread Tamás Gergely
@ 2003-03-14 16:50 ` Fergus Henderson
  2003-03-14 18:41   ` __thread Andreas Schwab
  0 siblings, 1 reply; 4+ messages in thread
From: Fergus Henderson @ 2003-03-14 16:50 UTC (permalink / raw)
  To: Tam?s Gergely; +Cc: gcc-help, gcc, Daniel Jacobowitz, mohamed.abbas

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: __thread
  2003-03-14 16:50 ` __thread Fergus Henderson
@ 2003-03-14 18:41   ` Andreas Schwab
  2003-03-17 16:27     ` glibc problems with snapshot Tamás Gergely
  0 siblings, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2003-03-14 18:41 UTC (permalink / raw)
  To: Fergus Henderson
  Cc: Tam?s Gergely, gcc-help, gcc, Daniel Jacobowitz, mohamed.abbas

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."

^ permalink raw reply	[flat|nested] 4+ messages in thread

* glibc problems with snapshot
  2003-03-14 18:41   ` __thread Andreas Schwab
@ 2003-03-17 16:27     ` Tamás Gergely
  0 siblings, 0 replies; 4+ messages in thread
From: Tamás Gergely @ 2003-03-17 16:27 UTC (permalink / raw)
  To: gcc-help; +Cc: gcc



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 *
**************************************************************************

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-03-17 11:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-14 16:25 __thread Tamás Gergely
2003-03-14 16:50 ` __thread Fergus Henderson
2003-03-14 18:41   ` __thread Andreas Schwab
2003-03-17 16:27     ` glibc problems with snapshot Tamás Gergely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).