RE: [PATCH] Fix PR ipa/64049

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

Hi Honza,

On Tue, 9 Dec 2014 00:16:36, Jan Hubicka wrote:
>
>>> On Mon, Dec 8, 2014 at 11:57 AM, Bernd Edlinger
>>> <bernd.edlinger@hotmail.de> wrote:
>>>>
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>> this surprisingly simple patch fixes PR ipa/64049. The root cause seems to be
>>>>> that in this test case we try to devirtualize a method call on a return value.
>>>>>
>>>>>
>>>>> Boot-Strapped and regression-tested on X86_64-linux-gnu.
>>>>> OK for trunk?
>>>
>>> I think positive tests, in this case TREE_CODE (...) == VAR_DECL
>>> are better.
>>>
>>> Ok with that change.
>>
>> The test there assumes that only values with well defined default value are parm decls,
>> so in cases we see a call on default value of other kind of decl, we could turn it
>> to undefined call.
>>
>> In what cases has RESULT_DECL sane initial value? We should at least drop a comment here.
>
> I assume those are DECL_BY_REFERENCE return values. Then we probably want
> TREE_CODE (...) == VAR_DECL || (TREE_CODE (...) == RESULT_DECL && !DECL_BY_REFERENCE (...))?
>
> Honza


BTW: I have never seen any VAR_DECL here, at least not in my test case, do you have test cases for that?

The condition here was if TREE_CODE(..) != PARM_DECL, and I extended it to be
TREE_CODE (..) == PARM_DECL ||| TREE_CODE (..) == RESULT_DECL.

That was purely by heuristic, the intention was to change as little as possible, so
refining that to TREE_CODE (...) == PARM_DECL || (TREE_CODE (...) == RESULT_DECL && !(DECL_BY_REFERENCE (...)))
would be fully consistent with my heuristic.

I don't have much more than the example where this RESULT_DECL showed up here.
If this extra condition does not make the test case fail, it would be OK for me.

But why is a RESULT_DECL per se undefined?

Do you have a test case, where this extra condition would make a difference?


Thanks,
Bernd.