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

[Jeff Law]

On 01/26/2016 12:01 AM, Richard Biener wrote:
> On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher <debian@mkarcher.dialup.fu-berlin.de> 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
>> not
>> 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
>> upstream
>> 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.

Jeff