This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On January 26, 2016 8:03:35 PM GMT+01:00, Michael Karcher <> wrote:
>On 26.01.2016 16:40, Richard Biener wrote:
>> No, the patch looks somewhat broken to me.  A complete fix would
>> 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
>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
>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.
>%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

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


>  Michael Karcher

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]