This is the mail archive of the
newlib@sourceware.org
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?
On 31/08/16 12:36, Schwarz, Konrad wrote:
>> -----Original Message-----
>> From: Richard Earnshaw (lists) [mailto:Richard.Earnshaw@arm.com]
>> Sent: Wednesday, August 31, 2016 1:15 PM
>> To: Schwarz, Konrad (CT RDA ITP SES-DE); newlib@sourceware.org
>> Subject: Re: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums)
>> | Remove hard coded short enum flag from the build scripts?
>
>> GCC/GAS/LD on ARM systems emit Build Attributes[1]. One of these
>> attributes describes the way in which the file depends on how enum
>> types are handled (since in an ABI it *can* affect whether the files
>> are compatible with each other). Unfortunately, GCC has a limitation
>> in that it only supports two of the four possible attribute values for
>> this particular attribute since we can't get at enough details in the
>> mid/front end to validate the user's code complies with the attribute
>> settings.
>
> But wouldn't it suffice to allow the user to select (or override) the
> build attribute to set on the file, e.g., via a compiler command line switch?
>
Yes, but 1) we have no builds of GCC available *today* that can do that
and 2) experience has shown that such 'power user' options generally
confuse most users and lead to more problems than they really solve
unless they can validate the user's assertions.
> Obviously, this requires the compiler to trust the user.
>
> Conversely, as there is no way in (standard) C to distinguish
> an ABI from interfaces internal to the implementation,
> any scheme to determine this build attribute automatically
> cannot be fully satisfactory, no?
>
No, this is nothing to do with standard C. The C standard just thinks
about enums at the conceptual level. It doesn't grubby its hands with
nasty details like ABIs or layout in general... The idea that this
might be changed in different translation units is completely off-piste.
R.