On January 26, 2016 8:25:50 AM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 01/26/2016 12:01 AM, Richard Biener wrote: >> On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher ><deb...@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.
What I wanted to say is that we preserve the function type used for the actual call at least until RTL expansion in gimple_call_fntype. I fixed most of the call expansion code to honor that but back ends may of course screw up as they still may somehow get at the actual DECL called. Richard. >Jeff
