From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38163 invoked by alias); 30 Aug 2016 18:28:10 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 38154 invoked by uid 89); 30 Aug 2016 18:28:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=tough, delegates, newlib-owner@sourceware.org, U*newlib-owner X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Aug 2016 18:27:59 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 772C380F6C for ; Tue, 30 Aug 2016 18:27:58 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7UIRvOW007728 for ; Tue, 30 Aug 2016 14:27:58 -0400 Received: by calimero.vinschen.de (Postfix, from userid 500) id 6FCDAA8059C; Tue, 30 Aug 2016 20:27:57 +0200 (CEST) Date: Tue, 30 Aug 2016 18:28:00 -0000 From: Corinna Vinschen To: 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? Message-ID: <20160830182757.GC5955@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <86388ac2-70e3-2a15-a021-cab3b0dea9fe@pahl.de> <20160830094718.GB23664@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) X-SW-Source: 2016/txt/msg01035.txt.bz2 --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2373 On Aug 30 13:16, Schwarz, Konrad wrote: > > -----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? >=20 > This is a surprisingly tough question to answer. >=20 > The AAPCS for ABI release 2.10, (current ARM ABI) says: >=20 > 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. >=20 > 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). >=20 > 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]. >=20 > 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. >=20 > GCC's manual has the following to say (this is target-independent): >=20 > *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. >=20 > So GCC seems to think that -fshort-enums should be used only in > exceptional circumstances. >=20 > 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. Given that, per Richard, the enum usage in the affected files is internal a change here is apparently not ABI-relevant. From my rather neutral stance it looks like a pretty safe change so far... Corinna --=20 Corinna Vinschen Cygwin Maintainer Red Hat --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXxdAtAAoJEPU2Bp2uRE+gC/kP/2bqQVIpqJ0upAupoxEFsaDT skyCaApThXcYDkmiXOSWYqXwbBy1GqNlpddZjkCuZrzpMCG1ey+YO3Gag5DBrd9M SQa4AIoLc+aoufa/OlcBoy4aTcsY6uMcmIYn25TtyBa4DRn38G9rRqSaGnWJoTRR 4obmRFEzmaaOQB8luOq+SnGa0tJwi0Dj+qj/CPQZoicNFQHTnueXUWuIu+rEIBAR RXJHRiYu/L4PcRNXjfFhD+ebG9zmptYh9WqiS1OXfbtUevNgRYfbgeYxVFzhNeBy /zB7nZGxWIZRZXLtH01byuEvyp65v2k1Lxp3rlwKl5fUR/5E6XTCTFFL7nTUOr9e AehmzZ3bdvbiqzxKLC5J+R79O70u7ja/LoscLXDluJKjhKfpv4X0uCI/hiHxLYoW ZKxec/F8c9+4z8Nb5VoaHESaQwq1a4l/EFGszBUIJiyzmXWLHyYJqDw1t5kFmLaw ezEzhe59U8inpWQOtHxjW7DH2WujF39GNcR4gQII6O1Z0sXssJPhv7pcjVVzuLp2 L6y7JTbDjXODxW4Fqd4zNApnKJAE+8hrMc69wvNwi6AsFAFDRJIIE8NajoKt+Q8U Vsd9uyampNw38Ryv6s7xAQNysBX/goWdQk4nnpm+uB7ynWqgPNf93wpy8M/FP3YN RM9IA9mkyflRUZEBpVf7 =oegJ -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/--