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

[Corinna Vinschen]

On Aug 30 14:07, Richard Earnshaw (lists) wrote:
> On 30/08/16 10:47, Corinna Vinschen wrote:
> > On Aug 28 16:31, Dennis Pahl wrote:
> >> 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
> >> specifying
> >> 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[1].
> 
> 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.

Yeah, "somebody" would have to do that.  However, if the enums in the
affected files are only used internally, what could possible go wrong?
*duck*

On a more serious note, if, as you say, memory-conscious bare-metal ARM
builds use -fshort-enums anyway, they don't need the flag hard coded for
a handful of files in the lib since the entire lib will use this flag.

While builds which don't use -fshort-enums are in all likelyhood not as
memory-conscious anyway and won't profit much from the few lib files
built with this flag.

So, from a neutral perspective, I'd say the special handling of these
files only makes marginal sense and could go away, isn't it?  Am I
missing something?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160830/4726573b/attachment.sig>