GCC problem (Was: Re: [bugs] Problem compiling the kernel)

GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Bo Thorsen]

On Friday 07 December 2001 13:26, Bo Thorsen wrote:
> There is a problem compiling the kernel now, but I can't see if this is a
> gcc or kernel problem.

I just made a good simplification on this one:

----- problem.c -----

typedef struct { } spinlock_t;
spinlock_t runqueue_lock
  __attribute__((__aligned__((1 << ((6)))),
  __section__(".data.cacheline_aligned"))) = (spinlock_t) { };

----- problem.c -----

> ../crossbuild/x86-64/bin/x86_64-unknown-linux-gcc problem.c
problem.c:4: initializer element is not constant

ia32 gcc works fine.

Ideas on how this has come to be?

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Andreas Jaeger]

Bo Thorsen <bo@sonofthor.dk> writes:

> On Friday 07 December 2001 13:26, Bo Thorsen wrote:
>> There is a problem compiling the kernel now, but I can't see if this is a
>> gcc or kernel problem.
>
> I just made a good simplification on this one:
>
> ----- problem.c -----
>
> typedef struct { } spinlock_t;
> spinlock_t runqueue_lock
>   __attribute__((__aligned__((1 << ((6)))),
>   __section__(".data.cacheline_aligned"))) = (spinlock_t) { };
>
> ----- problem.c -----
>
>> ../crossbuild/x86-64/bin/x86_64-unknown-linux-gcc problem.c
> problem.c:4: initializer element is not constant
>
> ia32 gcc works fine.

That's not right, it fails also on i686-linux:

$ /opt/gcc-3.1-devel/bin/gcc problem.c 
problem.c:4: initializer element is not constant

$ /opt/gcc-3.1-devel/bin/gcc problem.c  -v
Reading specs from /opt/gcc-3.1-devel/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: /cvs/gcc/configure --prefix=/opt/gcc-3.1-devel --enable-shared --enable-threads=posix --enable-clocale=gnu --with-gnu-as --with-gnu-ld --disable-nls --with-system-zlib --enable-languages=c,c++
Thread model: posix
gcc version 3.1 20011206 (experimental)
 /opt/gcc-3.1-devel/lib/gcc-lib/i686-pc-linux-gnu/3.1/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ problem.c -quiet -dumpbase problem.c -version -o /tmp/cctD4Wsi.s
GNU CPP version 3.1 20011206 (experimental) (cpplib) (i386 Linux/ELF)
GNU C version 3.1 20011206 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.1 20011206 (experimental).
[...]

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Joseph S. Myers]

On Mon, 10 Dec 2001, Bo Thorsen wrote:

> typedef struct { } spinlock_t;
> spinlock_t runqueue_lock
>   __attribute__((__aligned__((1 << ((6)))),
>   __section__(".data.cacheline_aligned"))) = (spinlock_t) { };
> 
> ----- problem.c -----
> 
> > ../crossbuild/x86-64/bin/x86_64-unknown-linux-gcc problem.c
> problem.c:4: initializer element is not constant
> 
> ia32 gcc works fine.
> 
> Ideas on how this has come to be?

No-one spoke up in favour of this extension (treating compound literals as
if they were the brace-enclosed lists they contain) when I asked
<URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it when
implementing proper C99 semantics for compound literals.  A compound
literal, as an expression here of structure type, is not a valid
initializer for an object of static storage duration.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [bugs] Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Andreas Jaeger]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Mon, 10 Dec 2001, Bo Thorsen wrote:
>
>> typedef struct { } spinlock_t;
>> spinlock_t runqueue_lock
>>   __attribute__((__aligned__((1 << ((6)))),
>>   __section__(".data.cacheline_aligned"))) = (spinlock_t) { };
>> 
>> ----- problem.c -----
>> 
>> > ../crossbuild/x86-64/bin/x86_64-unknown-linux-gcc problem.c
>> problem.c:4: initializer element is not constant
>> 
>> ia32 gcc works fine.
>> 
>> Ideas on how this has come to be?
>
> No-one spoke up in favour of this extension (treating compound literals as
> if they were the brace-enclosed lists they contain) when I asked
> <URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it when

Seems that nobody noticed this.:-(  The Linux kernel relies on this
(that's where the example is from) and it seems to work with GCC
2.95.x and GCC 3.0 also.

> implementing proper C99 semantics for compound literals.  A compound
> literal, as an expression here of structure type, is not a valid
> initializer for an object of static storage duration.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Jakub Jelinek]

On Mon, Dec 10, 2001 at 03:38:10PM +0000, Joseph S. Myers wrote:
> On Mon, 10 Dec 2001, Bo Thorsen wrote:
> 
> > typedef struct { } spinlock_t;
> > spinlock_t runqueue_lock
> >   __attribute__((__aligned__((1 << ((6)))),
> >   __section__(".data.cacheline_aligned"))) = (spinlock_t) { };
> > 
> > ----- problem.c -----
> > 
> > > ../crossbuild/x86-64/bin/x86_64-unknown-linux-gcc problem.c
> > problem.c:4: initializer element is not constant
> > 
> > ia32 gcc works fine.
> > 
> > Ideas on how this has come to be?
> 
> No-one spoke up in favour of this extension (treating compound literals as
> if they were the brace-enclosed lists they contain) when I asked
> <URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it when
> implementing proper C99 semantics for compound literals.  A compound
> literal, as an expression here of structure type, is not a valid
> initializer for an object of static storage duration.

How big burden would to be keep supporting this in -std=gnu89 and -std=gnu99
modes? I don't think Linux kernel is the only user of this extension.

	Jakub

Re: [bugs] Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Joseph S. Myers]

On Mon, 10 Dec 2001, Andreas Jaeger wrote:

> > No-one spoke up in favour of this extension (treating compound literals as
> > if they were the brace-enclosed lists they contain) when I asked
> > <URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it when
> 
> Seems that nobody noticed this.:-(  The Linux kernel relies on this
> (that's where the example is from) and it seems to work with GCC
> 2.95.x and GCC 3.0 also.

Can Linux be fixed not to?  Because at the very least it makes no sense in
C99 mode for a compound literal to be other than an anonymous variable
initialized with particular contents, as specified in C99, and as soon as
the implementation of C99 is essentially finished (though I have no idea
when that will be) I intend to make -std=gnu99 the default, and I hope
Linux won't want to go around using the old standard by -std=gnu89 for
ever.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Joseph S. Myers]

On Mon, 10 Dec 2001, Jakub Jelinek wrote:

> How big burden would to be keep supporting this in -std=gnu89 and -std=gnu99
> modes? I don't think Linux kernel is the only user of this extension.

You're the expert on initializers in GCC, not me; you'd need to handle a
COMPOUND_LITERAL_EXPR specially for objects of static storage duration in
the appropriate place, and look at the DECL_INITIAL of the
COMPOUND_LITERAL_EXPR_DECL.  (Plus add a testcase and docs.)

The extension looked like a completely useless one, since (absent macros,
which I hadn't considered) why would anyone write the additional "(type)"
of the compound literal when they meant just the brace-enclosed list?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Joseph S. Myers]

On Mon, 10 Dec 2001, I wrote:

> You're the expert on initializers in GCC, not me; you'd need to handle a
> COMPOUND_LITERAL_EXPR specially for objects of static storage duration in
> the appropriate place, and look at the DECL_INITIAL of the
> COMPOUND_LITERAL_EXPR_DECL.  (Plus add a testcase and docs.)

All if !flag_isoc99 only, of course - I don't think we should perpetuate
this in gnu99 mode.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [bugs] Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Bo Thorsen]

On Monday 10 December 2001 16:57, Joseph S. Myers wrote:
> On Mon, 10 Dec 2001, Andreas Jaeger wrote:
> > > No-one spoke up in favour of this extension (treating compound literals
> > > as if they were the brace-enclosed lists they contain) when I asked
> > > <URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it
> > > when
> >
> > Seems that nobody noticed this.:-(  The Linux kernel relies on this
> > (that's where the example is from) and it seems to work with GCC
> > 2.95.x and GCC 3.0 also.
>
> Can Linux be fixed not to? 

I have spent a little time doing this. It's possible to remove the use of 
this extension from the kernel (obviously), but it's pretty painful. The 
macros using this are all over the place.

The problem is that you can't just change a MACRO(x) (x) { } to MACRO(x) { } 
since that gives a *lot* of compilation errors from various places where the 
cast is necessary. I'll give you one example of this necessity:

Excepts from include/linux/spinlock.h and include/linux/wait.h:

typedef struct { } rwlock_t;
#define RW_LOCK_UNLOCKED { }
#define WAITQUEUE_RW_LOCK_UNLOCKED RW_LOCK_UNLOCKED

struct __wait_queue_head {
  rwlock_t lock;
};

static inline void init_waitqueue_head(struct __wait_queue_head *q)
{
  q->lock = WAITQUEUE_RW_LOCK_UNLOCKED;
}

gcc_3.1 -c tmp.c
tmp.c: In function `init_waitqueue_head':
tmp.c:11: parse error before '{' token

But if I change the first define to

#define RW_LOCK_UNLOCKED (rwlock_t) { }

It's compiled without problems.

So, what's wrong here? The (rwlock_t) needs to be removed to make some parts 
compile, but then this problem surfaces. To me it looks like the extension is 
only partially gone, and this is one of the cases where it's still needed?

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: [bugs] Re: GCC problem (Was: Re: [bugs] Problem compiling the kernel)

[Andreas Schwab]

Bo Thorsen <bo@sonofthor.dk> writes:

|> On Monday 10 December 2001 16:57, Joseph S. Myers wrote:
|> > On Mon, 10 Dec 2001, Andreas Jaeger wrote:
|> > > > No-one spoke up in favour of this extension (treating compound literals
|> > > > as if they were the brace-enclosed lists they contain) when I asked
|> > > > <URL:http://gcc.gnu.org/ml/gcc/2001-11/msg01161.html>, so I killed it
|> > > > when
|> > >
|> > > Seems that nobody noticed this.:-(  The Linux kernel relies on this
|> > > (that's where the example is from) and it seems to work with GCC
|> > > 2.95.x and GCC 3.0 also.
|> >
|> > Can Linux be fixed not to? 
|> 
|> I have spent a little time doing this. It's possible to remove the use of 
|> this extension from the kernel (obviously), but it's pretty painful. The 
|> macros using this are all over the place.
|> 
|> The problem is that you can't just change a MACRO(x) (x) { } to MACRO(x) { } 
|> since that gives a *lot* of compilation errors from various places where the 
|> cast is necessary.

But we can introduce a separate macro just for initializing static
variables which would DTRT.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5