This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Support non-standard extension (call via casted function pointer)
- From: Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Debian m68k <debian-68k at lists dot debian dot org>, Andreas Schwab <schwab at linux-m68k dot org>, Matthias Klose <doko at debian dot org>
- Date: Tue, 26 Jan 2016 20:03:35 +0100
- Subject: Re: RFC: Support non-standard extension (call via casted function pointer)
- Authentication-results: sourceware.org; auth=none
- References: <56A697DE dot 5090207 at mkarcher dot dialup dot fu-berlin dot de> <85BF0BF8-F3BB-49F9-AA9F-5793017C7062 at gmail dot com> <56A73A99 dot 7030305 at physik dot fu-berlin dot de> <CAFiYyc0f7OzQqZQ72k9SwiPsmOBxTYPE2v88XahcJGJ_Y0zCGg at mail dot gmail dot com>
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
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))
Looks good and clean to me, but I expect my patch to have the same effect.