From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21465 invoked by alias); 17 Jun 2015 10:43:44 -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 21436 invoked by uid 89); 17 Jun 2015 10:43:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f170.google.com Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 17 Jun 2015 10:43:42 +0000 Received: by obbkn5 with SMTP id kn5so1505495obb.0 for ; Wed, 17 Jun 2015 03:43:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.79.194 with SMTP id d185mr3802131oib.46.1434537820253; Wed, 17 Jun 2015 03:43:40 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Wed, 17 Jun 2015 03:43:40 -0700 (PDT) In-Reply-To: <20150616221007.GA24640@kam.mff.cuni.cz> References: <20150611214743.GA59435@kam.mff.cuni.cz> <20150612080038.GE2756@redhat.com> <20150616221007.GA24640@kam.mff.cuni.cz> Date: Wed, 17 Jun 2015 10:51:00 -0000 Message-ID: Subject: Re: Fix verify_type ICE with -fshort-enum From: Richard Biener To: Jan Hubicka Cc: Marek Polacek , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg01189.txt.bz2 On Wed, Jun 17, 2015 at 12:10 AM, Jan Hubicka wrote: >> >> 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? Yes, it sounds like so. >> 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. IIRC it "works" for -m32, but yes... Yes also to _not_ make ABI changing flags 'Optimization'. Richard. > Honza >> >> Richard. >> >> > Please fix the formatting here: no space before ;. >> > >> > Ok with that change. >> > >> > Marek