This is the mail archive of the
mailing list for the newlib project.
RE: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?
- From: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>
- To: "newlib at sourceware dot org" <newlib at sourceware dot org>, Dennis Pahl <dennis at pahl dot de>
- Cc: "d dot pahl at pilz dot de" <d dot pahl at pilz dot de>, Matthew Wahab <matthew dot wahab at foss dot arm dot com>
- Date: Tue, 30 Aug 2016 13:16:48 +0000
- Subject: RE: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20160830094718.GB23664@calimero.vinschen.de>
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.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
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.