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.