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

[Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>]

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.

Regards,
  Michael Karcher