This is the mail archive of the
gcc@gcc.gnu.org
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: Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, gcc at gcc dot gnu dot org
- Cc: John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, Debian m68k <debian-68k at lists dot debian dot org>, Andreas Schwab <schwab at linux-m68k dot org>, doko at debian dot org
- Date: Tue, 26 Jan 2016 08:36:15 +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> <56A71F7E dot 3090402 at redhat dot com>
On 26.01.2016 08:25, Jeff Law wrote:
> I believe if they make the return type a pointer type, then the m68k
> backend ought to return the value in a0 and d0 to make broken code
> like this work. It may also be the case that we're not doing this
> properly for indirect calls from a quick scan of m68k_function_arg.
It works properly on the callee side: A function declared to return a
pointer returns in both a0 and d0.
On the caller side, a the result of a function returning a pointer is
expected in a0 (obviously correct for the SVR4/m68k ABI), even if a
"pointer-to-function returning int" is used to call that function.
(which is obviously undefined behaviour. See the linked ghc problem
report for chapter and verse). My patch makes ghc retrieve the value
from d0 instead of a0, if the actually returned value in the
call-expression has a non-pointer type, even if the called function is
known and declared as returning a pointer.
Regards,
Michael Karcher