This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Support non-standard extension (call via casted function pointer)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat 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 09:41:22 +0100
- 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> <56A71F7E dot 3090402 at redhat dot com>
On January 26, 2016 8:25:50 AM GMT+01:00, Jeff Law <law@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
><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.
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