> It looks like -fshort-enums (as embodied in gcc/c-decl.c::finish_enum())
> doesn't quite match the ARM ABI for enums.  Specifically, finish_enum()
> makes an enum signed iff it has any negative vlaues, whereas in the ARM
> ABI, 16-bit and 32-bit enums are signed by default (and only unsigned if
> they have values > 2^15 or 2^31 respectively).  This will need fixing:
> Richard?

1) I'm not sure this matters.  If the enum is of a range where it could 
fit into both signed or unsigned types of some size, then the value will 
never have it's top bit set, so sign-extension is equivalent to 
zero-extension.  If the top bit does matter, then it must be of a type 
that will hold the entire range of the enum.
2) I think this bit of the packed-enum spec will be cleaned up.  A test I 
ran on gcc yesterday seemed to match the latest draft of the enum spec 
that I have.



  An enumeration that can be represented by both the signed and unsigned
  versions of a basic type is allocated to a container of the unsigned 
type.
  Nonetheless, when used in an expression, an enumerated value converts to
  int unless it is a value of type unsigned int that is not a value of type
  int. 

R.