From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64935 invoked by alias); 16 Jun 2015 22:10:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 64925 invoked by uid 89); 16 Jun 2015 22:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 16 Jun 2015 22:10:11 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 7494A541EBC; Wed, 17 Jun 2015 00:10:07 +0200 (CEST) Date: Tue, 16 Jun 2015 22:16:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Marek Polacek , Jan Hubicka , GCC Patches Subject: Re: Fix verify_type ICE with -fshort-enum Message-ID: <20150616221007.GA24640@kam.mff.cuni.cz> References: <20150611214743.GA59435@kam.mff.cuni.cz> <20150612080038.GE2756@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-06/txt/msg01171.txt.bz2 > >> PR middle-end/66325 > >> * c-decl.c (start_enum): Set TYPE_PACKED consistently among type variants. > >> Index: c-decl.c > >> =================================================================== > >> --- c-decl.c (revision 224250) > >> +++ c-decl.c (working copy) > >> @@ -7946,7 +7946,8 @@ > >> the_enum->enum_overflow = 0; > >> > >> if (flag_short_enums) > >> - TYPE_PACKED (enumtype) = 1; > >> + for (tree v = TYPE_MAIN_VARIANT (enumtype); v ;v = TYPE_NEXT_VARIANT (v)) > > Though I wonder why flag_short_enums was not true when building the > (main-)variant? What I believe happens is that there is forward declaration of enum that leads to biuld incomplete enum type that has no packed flag set. Then we produce a type variant and after that we complete the main variant, but do not update the other variant. Actually looking into where the variant is updated, it happens in finish_enum that copies many flags, perhaps it would make more sense to copy TYPE_PACKED there? > Looks like -fshort-enums is also 'Optimization', so the above is bogus for > > enum foo {x = 1 }; > > void __attribute__((optimize(short-enums))) foo() > { > const enum foo x = 1; > } > > no? The main variant is correctly _not_ packed but now you make it > packed as you reach foo ()? Perhaps it is defined as Optimization but it does not bind to uses of types: enum foo {a,b,c}; __attribute__((optimize("short-enums"))) main() { const enum foo x; enum bar {a,b,c}; printf ("%i %i\n",sizeof (x), sizeof(enum bar)); } prints 4 1 it depends when the main variant is finished. I wonder if there is any practical value on support Optimization attribute for this kind of ABI breaking options. It may be easier to simply drop the Optimization flag completely from -fshort-enums and friends. -fshort-double ICEs at initialization time at least since 4.8.x $ gcc t.c -fshort-double : internal compiler error: in layout_type, at stor-layout.c:2220 0xafe41b layout_type(tree_node*) ../../gcc/stor-layout.c:2219 so I suggest dropping that flag completely. Honza > > Richard. > > > Please fix the formatting here: no space before ;. > > > > Ok with that change. > > > > Marek