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.edlin...@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.
