On Aug 30 13:16, Schwarz, Konrad wrote:
> > -----Original Message-----
> > From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> > On Behalf Of Corinna Vinschen
> > The patch is ok with me, what do other user's of ARM think?
> 
> This is a surprisingly tough question to answer.
> 
> The AAPCS for ABI release 2.10, (current ARM ABI) says:
> 
> 	This ABI delegates a choice of representation of enumerated
> 	types to a platform ABI (whether defined by a standard or by
> 	custom and practice) or to an interface contract if there is no
> 	defined platform ABI.
> 
> It also notes: Under this ABI, these statements allow a header file
> that describes the interface to a portable binary package to force its
> clients, in a portable, strictly-conforming manner, to adopt a 32-bit
> signed (int/long) representation of values of enumerated type (by
> defining a negative enumerator, a positive one, and ensuring the range
> of enumerators spans more than 16 bits but not more than 32).
> 
> The ABI-Addenda defines a specific Tag_ABI_enum_size value for this
> usage, in addition to the cases [no enums permitted], [smallest
> container], and [32-bit enums].
> 
> It used to say (in r2.05): The type of the storage container for an
> enumerated type is the smallest integer type that contains all the
> enumerated values.
> 
> GCC's manual has the following to say (this is target-independent):
> 
>      *Warning:* the '-fshort-enums' switch causes GCC to generate code
>      that is not binary compatible with code generated without that
>      switch.  Use it to conform to a non-default application binary
>      interface.
> 
> So GCC seems to think that -fshort-enums should be used only in
> exceptional circumstances.
> 
> I'm unclear where newlib uses enums in its ABI, but the AAPCS
> suggestion of enforcing minimal enum sizes via appropriately sized
> integer constants (and ensuring that all enums in newlib have exactly
> 32 bits) and using the right Tag_ABI_enum_size should allow code
> compiled with -fshort-enums or with -fno-short-enums to link to
> newlib.

Given that, per Richard, the enum usage in the affected files is
internal a change here is apparently not ABI-relevant.  From my
rather neutral stance it looks like a pretty safe change so far...


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat