Re: [RFC] PR 59776 - esra vs gimple_debug

[Richard Biener <richard dot guenther at gmail dot com>]

On Sat, Feb 8, 2014 at 1:37 AM, Richard Henderson <rth@redhat.com> 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.

What do you mean with "check"?  We have stmt verifiers in tree-cfg.c but they
skip debug statement contents because "those may contain anything" (including
crap it seems ;)).  That was an early design decision appearantly - given the
above ICE maybe not the best one.

IIRC the debug stmt expander is the one that is supposed to throw away anything
it cannot handle (and thus it has to expect any sort of werid stuff).

Richard.

>
> r~