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: Florian Weimer <fweimer at redhat dot com>
- Cc: Thorsten Otto <halgara at yahoo dot de>, Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, GCC Development <gcc at gcc dot gnu dot org>, Debian m68k <debian-68k at lists dot debian dot org>, Andreas Schwab <schwab at linux-m68k dot org>, Matthias Klose <doko at debian dot org>
- Date: Thu, 28 Jan 2016 12:33:25 +0100
- Subject: Re: RFC: Support non-standard extension (call via casted function pointer)
- Authentication-results: sourceware.org; auth=none
- References: <56A7C307 dot 3010701 at mkarcher dot dialup dot fu-berlin dot de> <1824417918 dot 1565020 dot 1453907423941 dot JavaMail dot yahoo at mail dot yahoo dot com> <CAFiYyc0fAj3Dq6SEySEf93_Fx0heK5nh9VRrY-u8VNDePyqYdw at mail dot gmail dot com> <56A9E966 dot 3090708 at redhat dot com>
On Thu, Jan 28, 2016 at 11:11 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/27/2016 04:17 PM, Richard Biener wrote:
>
>> We are trying to support
>>
>> t.c
>> ---
>> void *foo();
>>
>> int bar()
>> {
>> return ((int (*)())foo) ();
>> }
>>
>> t2.c
>> -----
>> int foo () { return 0; }
>>
>> thus doing a direct call to a function with a (wrong) prototype via a function
>> pointer cast to the correct type and having a matching implementation of
>> that function elsewhere.
>
> I suspect Ada needs something like this already. I expect the following
> to work (although it is quite hideous).
>
> with System;
>
> package Import is
>
> function Foo return System.Address;
> pragma Import (C, Foo);
>
> function Bar return Integer;
>
> end Import;
>
> package body Import is
>
> function Bar return Integer is
> function Foo_2 return Integer;
> pragma Import (C, Foo_2);
> for Foo_2'Address use Foo'Address;
> begin
> return Foo_2;
> end Bar;
>
> end Import;
Heh. Well, the real reason for officially (aka in GCCs middle-end)
supporting this
is LTO and cross-language calls. You hardly can get 1:1 matching declarations
there and penaltizing all of them by forcing us to go through indirect calls
(which backends handle just fine) is no good.
What the middle-end policy does is simply that the generated code should
match the source input call ABI used (which is specified by the function
type a call is carried out on). That makes sense from a QOI perspective anyway.
And yes, it looks like the m68k backend is simply buggy here.
Richard.
>
> Florian