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 January 26, 2016 8:25:50 AM GMT+01:00, Jeff Law <> wrote:
>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
>>> not
>>> compiled as intended on m68k. This is because its internal Cmm (a
>>> dialect) to C compiler needs to declare external functions (no
>>> without fixing the type. It currently uses
>>> 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.
>>> model currently works fine (possibly by accident) on all
>>> 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,
>>> 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

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.



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