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 01/26/2016 12:01 AM, Richard Biener wrote:
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher <> wrote:
Hello gcc developers,

as discussed in (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.
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.

The only way to know for sure would be to examine it under the debugger.


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