http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52329
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-02-22
Ever Confirmed|0 |1
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22
09:47:35 UTC ---
# DEBUG D#7 => &s.c.D.2422
seems to be
<addr_expr 0x7ffff5821e60
type <pointer_type 0x7ffff5bb5930
...
arg 0 <component_ref 0x7ffff5c06ce8 type <record_type 0x7ffff5bb5888 G>
arg 0 <mem_ref 0x7ffff5c0cb40 type <record_type 0x7ffff5bbd0a8 J>
arg 0 <addr_expr 0x7ffff5821618 type <pointer_type 0x7ffff5bc3d20>
arg 0 <component_ref 0x7ffff5c06ea8 type <record_type
0x7ffff5bbd0a8 J>
arg 0 <var_decl 0x7ffff5a298c0 s> arg 1 <field_decl
0x7ffff5baeda8 c>>
thus &(MEM_REF (&s.c).D.2422). What is not ok is that the first operand
of the MEM_REF is not is_gimple_mem_ref_addr ().
Valid would be &(MEM_REF (&s + 0).D.2422) for example, which fold would
canonicalize the MEM_REF sub-tree to.
Unfortunately we do not verify anything in gimple_debug stmts :(
[sorry for the un-obfuscation during pretty-printing ;)]
It seems that this is introduced by propagating into debug stmts as we go
from
t.ii.058t.copyrename2: # DEBUG D#4 => &D.2734_8->D.2422
t.ii.058t.copyrename2: # DEBUG this => D#4
to
t.ii.060t.ccp2: # DEBUG D#4 => &s.c.D.2422
t.ii.060t.ccp2: # DEBUG this => D#4
and the issue there seems to be that GIMPLE_DEBUG handling in fold_stmt
does not look at ADDR_EXPRs but only REFERENCE_CLASS_P stuff. See
the ADDR_EXPR handling in fold_gimple_assign.
