Re: RFC: Support non-standard extension (call via casted function pointer)

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

On January 26, 2016 8:03:35 PM GMT+01:00, Michael Karcher <debian@mkarcher.dialup.fu-berlin.de> wrote:
>On 26.01.2016 16:40, Richard Biener wrote:
>> No, the patch looks somewhat broken to me.  A complete fix would
>replace
>> the target macro FUNCTION_VALUE implementation by implementing the
>> function_value hook instead (to also receive the function type called
>if no
>> decl is available and to be able to distinguish caller vs. callee).
>>
>> I also don't see how changing the called function code will fix
>anything.
>I definitely agree that the approach to move from the FUNCTION_VALUE
>macro to the function_value hook is the most clean way to do it. If
>there is a consensus among the gcc developers that a patch to support
>this non-conforming code should be applied, I would be willing to
>prepare a patch as suggested.
>
>The current patch does not change the called code at all. The only time
>at which my suggested patch changes gcc behaviour is if a function
>declaration is given, that declaration has a pointer type as return
>type, but valtype is no pointer type. This (unverified claim) can not
>happen in the callee, as the valtype when compiling the return
>statement
>or assembling the epilogue is taken from the function declaration.
>
>> In fact the frobbing of the return value into %d0 should only happen
>> if the 'outgoing' arg is true (in the hook implementation) and in the
>> 'outgoing' == false case simply disregard 'func' and always use
>> 'valtype'.
>This frobbing of a pointer return value in %d0 only happens in the
>outgoing case already now, because in the non-outgoing case,
>m68k_function_value is (unverified claim) only called from expand_call,
>which replaces the PARALLEL rtx by the first list element, i.e. %a0.
>(or
>%d0 if !POINTER_TYPE_P(valtype) after my patch).
>
>> So, hookize and change to
>>
>>   if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func))))
>>     ...
>>   else if (POINTER_TYPE_P (valtype))
>>    ...
>>  else
>>    ...
>Looks good and clean to me, but I expect my patch to have the same
>effect.

I would still prefer the more obvious approach of using the target hook transition.

Richard.

>
>Regards,
>  Michael Karcher