http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097
--- Comment #3 from rguenther at suse dot de <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 <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? 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.
