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

[Bo Thorsen <bo at sonofthor dot dk>]

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