This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?


> -----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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]