> That helps reproducing it. The issue is that this really is a transition > in the wrong direction. We iterate > > Visiting statement: > D.2928_263 = (sizetype) i.29_262; > which is likely UNDEFINED > Lattice value changed to UNDEFINED. Adding SSA edges to worklist. > ... > Visiting statement: > D.2930_265 = (sizetype) j.30_264; > which is likely CONSTANT > Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. > ... > Visiting statement: > elem_266 = &arr[D.2928_263][D.2930_265]; > which is likely CONSTANT > Lattice value changed to CONSTANT Lattice value changed to CONSTANT > 0x00000000000000000 (0x0fffffffffffffffc). Adding SSA edges to > worklist. > > ... 2nd iteration: > > Visiting statement: > D.2928_263 = (sizetype) i.29_262; > which is likely CONSTANT > Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. > ... > Visiting statement: > elem_266 = &arr[D.2928_263][D.2930_265]; > which is likely CONSTANT > > so the error is that in the 1st iteration when visiting elem_266 we do not > treat D.2928_263 optimistically enough. We could either derive a > lattice-value of &arr[0][0] or simply make it UNDEFINED (which sounds > like the easier solution).
OK, thanks for the explanation. > So I'm testing the following > > Index: gcc/tree-ssa-ccp.c > =================================================================== > --- gcc/tree-ssa-ccp.c (revision 189646) > +++ gcc/tree-ssa-ccp.c (working copy) > @@ -648,6 +649,11 @@ likely_value (gimple stmt) > the undefined operand may be promoted. */ > return UNDEFINED; > > + case ADDR_EXPR: > + /* If any part of an address is UNDEFINED, like the index > + of an ARRAY_EXPR, then treat the result as UNDEFINED. */ > + return UNDEFINED; > + > default: > ; > } I can do the full testing if you're happy with it. -- Eric Botcazou
