This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [parisc-linux] 2.4.20-pa27 64bits smp problem!
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: willy at debian dot org (Matthew Wilcox)
- Cc: willy at debian dot org, parisc-linux at parisc-linux dot org, gcc at gcc dot gnu dot org
- Date: Wed, 26 Feb 2003 16:13:11 -0500 (EST)
- Subject: Re: [parisc-linux] 2.4.20-pa27 64bits smp problem!
> On Wed, Feb 26, 2003 at 01:58:57PM -0500, John David Anglin wrote:
> > > Would I have to open a bug report near gcc with this one?
> >
> > You mean for the errors:
> >
> > joel.c:19: error: initializer element is not constant
> > joel.c:19: error: (near initialization for `MyRWLock')
> > joel.c:19: error: initializer element is not constant
> >
> > No, fix the code. I don't believe you will win this one. This
> > feature (extension) was deliberately removed from GCC.
>
> I think it was an error to do so. I do not see how
>
> (spinlock_t) { 1 }
>
> is any more or less constant than
>
> { 1 }
>
> Removing this extension is a bad idea because it removes the ability to
> do typechecking. For example,
>
> rwlock_t lock = SPIN_LOCK_INIT;
>
> would throw an error with a cast and not without.
GCC allows the above cast. What is not ok is a non-arithmentic cast
operator within an arithmetic constant expression (initializer). In
ISO C, cast operators in an arithmetic constant expression shall only
convert arithmetic types to arithmetic types, except as part of an
operand to the sizeof operator. See section 6.6 in the ISO C standard.
Joel's example contained a non-arithmetic cast within an arithmetic
expression. Possibly, GCC could have continued to allow casts to
aggregate types, but a decision was made not to. I know glibc has
had to adapt similar code.
Dave
--
J. David Anglin dave dot anglin at nrc-cnrc dot gc dot ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)