[RFC] PR 59776 - esra vs gimple_debug

[Martin Jambor]

Hi,

On Fri, Feb 07, 2014 at 04:37:22PM -0800, Richard Henderson wrote:
> On 02/07/2014 03:12 PM, Richard Biener wrote:
> > On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson <rth@redhat.com> wrote:
> >> In the testcases with the PR, we have a bit of type punning going on,
> >>
> >>  *(int *) &s2.f = 0;
> >>  s2 = s1;
> >>
> >> which SRA trasforms to
> >>
> >>  # DEBUG s2 => 0
> >>  MEM[(int *)&s2] = 0;
> >>  # DEBUG s2 => s1$f_7
> >>  # DEBUG s2$g => s1$g_6
> >>  s2 ={v} {CLOBBER};
> >>
> >> Note that it has chosen not to expand s1.f like s1.g, but to expand
> >> that field
> >> as the type-punned integer.  Which means that "s2 => s1$f_7" has
> >> mismatched
> >> types across lhs and rhs: SI => SF.  Which understandibly ICEs during
> >> rtl
> >> expansion.
> >>
> >> I'm not really sure how this is avoided for the actual code generation,
> >> but
> >> this minimal patch (aka hack) simply drops the debug info to avoid the
> >> ICE.
> >>
> >> Thoughts on how this might really be solved?
> > 
> > Add a VIEW_CONVERT_EXPR around the rhs of the debug statement.
> 
> Well, ok, though I'm pretty sure that the debug info will pretty much barf on
> that immediately.
> 
> What I really meant is: where's a better place to put this check, since such a
> check _must_ exist somewhere else for the regular code generation.
> 

That is what SRA does for regular code, see the useless_type_conversion_p
check earlier in the same function.  If you want me to, I can prepare
the patch (at some point next week).

Thanks for analysis of the bug,

Martin