Subject: Re: Compilation / toolchain trouble
To: David Laight <david@l8s.co.uk>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm
Date: 03/19/2002 17:25:16
> On Tue, Mar 19, 2002 at 05:05:18PM +0000, Richard Earnshaw wrote:
> > > On Tue, 19 Mar 2002, David Laight wrote:
> > >
> > > : Why not add two lines to make it:
> > >
> > > : ___rtx_code_max = 16383,
> > > : ___rtx_code_min = -1,
> > >
> > > : That should stretch the enum to 16 bits...
> > >
> > > However, the compiler shouldn't be complaining that we explicitly reserve
> > > *more* space than is needed to store the enum values. (Less space might be
> > > a problem, but not more.)
> >
> > While C++ allows you to create a bit-field that is larger than the base
> > type, C does not. However, one could argue that in the case of a packed
> > enum that an excpetion could be made (up to the size that it would take if
> > it were not packed).
>
> Especially since enum bit fields are not part of C.
> So this is all up to gcc...
>
> Indeed, is using gcc specific code at all a good idea?
>
That's why the code is written as:
#ifdef ONLY_INT_FIELDS
#ifdef CODE_FIELD_BUG
unsigned int code : 16;
#else
unsigned short code;
#endif
#else
/* The kind of expression this is. */
enum rtx_code code : 16;
#endif
We want to use the enumeration if possible, since it makes debugging so
much easier.
R.