ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?
Richard Earnshaw (lists)
Tue Aug 30 13:07:00 GMT 2016
[Sorry, one more try]
[Apologies if you get this twice, I think I had a mail configuration
problem earlier today]
On 30/08/16 10:47, Corinna Vinschen wrote:
> On Aug 28 16:31, Dennis Pahl wrote:
>> in my project I need the enum size to be 4 bytes. Therefore in order to get
>> no linker compatibility warnings, I also require newlib to use 4 bytes for
>> its enums.
>> 4 byte enums can be achieved by specifying the following compiler flag
>> "-fno-short-enums". This flag works fine for the source code of my project.
>> Newlib, however, has a problem with this flag due to some hard coded
>> compiler invocations which include the opposite flag "-fshort-enums".
>> A look in the mailing list archive revealed, that there already has been a
>> discussion about this problem
>> (https://sourceware.org/ml/newlib/2013/msg00183.html). The final advice from
>> Michael Bruck, who started the discussion, was to remove these hard coded
>> flags entirely from the build script files. Is there a reason why this did
>> not happen?
Corinna asked for a patch, but none was forthcoming AFAICT. This is
OpenSource: you can't expect others to do the work for you.
>> With the removed hard coded flags the enum size can be configured by
>> CFLAGS_FOR_TARGET= '-fno-short-enums' or '-fshort-enums'
>> CXXFLAGS_FOR_TARGET='-fno-short-enums' or '-fshort-enums'
>> By following Michael Bruck's advice I was able to build newlib with the
>> wanted enum size.
> The patch is ok with me, what do other user's of ARM think?
I've just done some archaeology with some colleagues. It appears that
the initial addition of -fshort-enums was done by Jeff way back in 2002
(well before newlib nano). It also appears that it has been done only
for selected files - I presume this is because it is 'known' that these
functions do not export any dependencies on the size of an enum, so it
shaves a few bytes off their internal needs.
We've never noticed this before because the bare-metal ARM builds use
-fshort-enums by default, otherwise we would see build conflicts today
since gcc for ARM emits build attributes that describe the selection and
the linker will then fault incompatible object files.
So based on the above, I agree that this looks to be a sensible patch.
We'll have to check carefully that it doesn't break anything, however,
or cause any major code size regressions in existing configurations.
 Technically build attributes support describing more complex cases,
such as use enums for internal purposes only, but GCC has no way of
describing generating the complex cases or validating such claims by the
More information about the Newlib