public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "Schwarz, Konrad" <konrad.schwarz@siemens.com>
To: "newlib@sourceware.org" <newlib@sourceware.org>,
	       Dennis Pahl	<dennis@pahl.de>
Cc: "d.pahl@pilz.de" <d.pahl@pilz.de>,
	       Matthew Wahab	<matthew.wahab@foss.arm.com>
Subject: RE: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?
Date: Tue, 30 Aug 2016 13:17:00 -0000	[thread overview]
Message-ID: <A45B1767F1002449A37508C2CC6003D736993A@DEFTHW99EJ1MSX.ww902.siemens.net> (raw)
In-Reply-To: <20160830094718.GB23664@calimero.vinschen.de>

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

  parent reply	other threads:[~2016-08-30 13:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-28 14:31 Dennis Pahl
2016-08-30  9:47 ` ARM-only " Corinna Vinschen
2016-08-30 12:45   ` Joel Sherrill
2016-08-30 13:07   ` Richard Earnshaw (lists)
2016-08-30 18:23     ` Corinna Vinschen
2016-08-30 13:17   ` Schwarz, Konrad [this message]
2016-08-30 18:28     ` Corinna Vinschen
2016-08-30 23:26       ` Pavel Pisa
2016-08-31  7:56       ` Schwarz, Konrad
2016-08-31 11:15         ` Richard Earnshaw (lists)
2016-08-31 11:36           ` Schwarz, Konrad
2016-08-31 12:37             ` Richard Earnshaw (lists)
2016-08-31 12:44               ` Schwarz, Konrad
2016-08-31 14:33                 ` Richard Earnshaw (lists)
2016-08-31 16:04                   ` Richard Earnshaw (lists)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A45B1767F1002449A37508C2CC6003D736993A@DEFTHW99EJ1MSX.ww902.siemens.net \
    --to=konrad.schwarz@siemens.com \
    --cc=d.pahl@pilz.de \
    --cc=dennis@pahl.de \
    --cc=matthew.wahab@foss.arm.com \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).