[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

aldyh at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Feb 14 01:11:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> 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?



More information about the Gcc-bugs mailing list