From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22817 invoked by alias); 14 Feb 2012 09:04:09 -0000 Received: (qmail 22807 invoked by uid 22791); 14 Feb 2012 09:04:08 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Feb 2012 09:03:55 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0 Date: Tue, 14 Feb 2012 09:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: ice-on-valid-code, lto X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-02/txt/msg01394.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 --- Comment #3 from rguenther at suse dot de 2012-02-14 09:02:58 UTC --- On Tue, 14 Feb 2012, aldyh at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 > > Aldy Hernandez changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > > --- Comment #2 from Aldy Hernandez 2012-02-14 01:10:43 UTC --- > In get_bit_range() we get the following COMPONENT_REF: > > (gdb) call debug_generic_stmt(exp) > MEM[(struct io *)0B].e0; > > Then we extract the field so we can search for it in the original > record/structure: > > field = TREE_OPERAND (exp, 1); > record_type = DECL_FIELD_CONTEXT (field); > > But when we iterate through TYPE_FIELDS(record_type), "field" is not found > because the COMPONENT_REF's field "e0" has a different pointer than the "e0" in > the record itself: > > (gdb) call debug_generic_stmt (fld) > e0 > > (gdb) call debug_generic_stmt (field) > e0 > > (gdb) p fld == field > $12 = 0 > > I'm not very LTO savvy. Is this supposed to happen? Should we have been > comparing something else than pointer equality here, or is there something else > broken? Comparing the FIELD_DECL by pointer equality is indeed broken (but it happens to work without LTO). The type/IL checkers allow any FIELD_DECL that is type/position compatible with the one in the record. Now - in this simple testcase we merge the unnamed main variants of typedef struct { unsigned int e0 : 16; } s1; and typedef struct { unsigned int e0 : 16; } s2; because they are the same, which causes the variant lists (that contain s1 for one case and s2 for the other case) to be merged. Now, those variants still point to the original FIELD_DECL lists - for one variant it happens to be the "correct" one, for the other it's "wrong" (well, "wrong" if you assume that TYPE_FIELDs is shared amongst all type variants). I suppose we _can_ fix this in the type merging process (and that would even save some memory which is good). So I'll poke at this from the LTO side. Btw, my C++ memory model bitfield handling rewrite also fixes this bug. Richard.