http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-09
17:47:08 UTC ---
Seems the bug is that the DEBUG stmt created by SRA has
<var_decl 0x7ffff19a4e40 from$s_addr
type <integer_type 0x7ffff1996690 unsigned int sizes-gimplified asm_written
public unsigned SI
as the first operand, but
<mem_ref 0x7ffff17e0f78
type <record_type 0x7ffff17df1f8 in_addr sizes-gimplified asm_written
no-force-blk packed type_0 BLK
as the second operand (note the first one is SImode, the latter BLKmode).
Perhaps the packed attribute is what causes this, dunno. But we probably just
shouldn't emit a debug stmt if the mode is different, unless we can e.g. use a
COMPONENT_REF on it to get at the right mode.
Also, as the aggregate is actually used (in the call stmt a few stmts later),
I'd say SRA shouldn't emit the debug stmts for it at all, ideally for PR55579
we'd emit those only either if we'd SRA it anyway in the code (disregarding
debug), or if we have just stores but no uses of the aggregate.
Right now on trunk every SRA pass adds another set of debug stmts, because the
aggregate assignments aren't DCEd (as they are used).
Looking at this, perhaps we should defer PR55579 resolution for stage1 of 4.9,
so we have more time to e.g. think about some size limits what we still emit as
debug stmts and what not, etc.
Martin, what are your thoughts?
