From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125321 invoked by alias); 30 Aug 2016 18:23:49 -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 125284 invoked by uid 89); 30 Aug 2016 18:23:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=handful, H*R:D*sourceware.org, profit 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:23:38 +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 9A16781227 for ; Tue, 30 Aug 2016 18:23:37 +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 u7UINacP004361 for ; Tue, 30 Aug 2016 14:23:37 -0400 Received: by calimero.vinschen.de (Postfix, from userid 500) id 87C12A8059C; Tue, 30 Aug 2016 20:23:36 +0200 (CEST) Date: Tue, 30 Aug 2016 18:23: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: <20160830182336.GB5955@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="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) X-SW-Source: 2016/txt/msg01034.txt.bz2 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2725 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 be= en a > >> discussion about this problem > >> (https://sourceware.org/ml/newlib/2013/msg00183.html). The final advic= e from > >> Michael Bruck, who started the discussion, was to remove these hard co= ded > >> flags entirely from the build script files. Is there a reason why this= did > >> not happen? >=20 > Corinna asked for a patch, but none was forthcoming AFAICT. This is > OpenSource: you can't expect others to do the work for you. >=20 > >> With the removed hard coded flags the enum size can be configured by > >> specifying > >> CFLAGS_FOR_TARGET=3D '-fno-short-enums' or '-fshort-enums' > >> CXXFLAGS_FOR_TARGET=3D'-fno-short-enums' or '-fshort-enums' > >> > >> By following Michael Bruck's advice I was able to build newlib with the > >> wanted enum size. > >=20 > > The patch is ok with me, what do other user's of ARM think? >=20 > 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. >=20 > 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]. >=20 > 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 --=20 Corinna Vinschen Cygwin Maintainer Red Hat --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXxc8oAAoJEPU2Bp2uRE+gj1gP/Rs27Y+63xc/6E9QfePxgnAZ Kt3XlnRFyVvtHaC8Hz+ra7F2lES1KW0mvEblyj+Eeqb8o02QOIXN1ULCfP519+RN xTzsaEcwqsLwgxg2kaYebJhGIT9CS6S6m0cTxxiwv+LUkDRekW7x0W7e77aQkGkw Ey4fqMUvolQtx9vmF00FTnPQ9ugyUbri/sLWdvtXu9OGmbCtGRfcUAlXC3MZNnos 7xqk8RphHYxU8h/cNjcakUtg8Ae3kdE0h1hHBYHctJyqkD0OfqgAYiZ0uEnc2ofJ tkPn9NoHY+GExSBFEIwd41G04iQ2wViXO1SOcfaXFWqcsI4ORlqFieKSZyT0oc0+ nHxsnmB1G/yqSUYiFI3sAWgTmy8yE3aEjIlGM+bNonkKZFaNE1d4BbkqQIzBN8Io HxaEyJ9/qE/5EJhhLNzF1cK8bX+7CU0zlOnNNsc+HBO1CS4NpkFwZQaMOyhzU2Y5 TIQugyU6+XQA3zXutUksN1U7qXvjnoebe367rNoo+LnOqT4IzK477vZ5qs2l4O5u Dt9qEs8xhU/CM5zr2TGuCGY/aWHnfk4l6wai1cIPxHn/kDB23eBIIzkzavipdePp 3MafE6NrgMQ9PCio+xY6t09MYvR4TYDbe5cd5XEvjlFvDOfEbNiQBVgPMM7jHlqa aQWWfX/YYvZCeFuoP5IF =rGIH -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--