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: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>, 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 00:25:50 -0700
- 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>
On 01/26/2016 12:01 AM, Richard Biener 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.
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher <firstname.lastname@example.org> wrote:
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is
compiled as intended on m68k. This is because its internal Cmm (a C--
dialect) to C compiler needs to declare external functions (no varargs)
without fixing the type. It currently uses "unspecified-function-type*
function();" which is a quite good fit, because the argument list is
still left open, but it fixes the return type to some pointer type.
Before calling that function, the function address is put into a
function pointer of the correct type and invoked via that pointer. This
model currently works fine (possibly by accident) on all architectures
ghc supports except m68k.
I developed a gcc patch that does not change the code generation for
conforming programs but fixes this non-conforming use-case by always
taking the actual return type in the call expression into account, even
if the function declaration to be called is known. Please comment
whether such a patch has any chance to be applied to either gcc
or gcc in Debian.
Without looking at the patch this is already how GCC should behave for all targets.
The only way to know for sure would be to examine it under the debugger.