This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Support non-standard extension (call via casted function pointer)
- From: Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>
- To: Thorsten Otto <halgara at yahoo dot de>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: 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: Wed, 27 Jan 2016 22:33:04 +0100
- Subject: Re: RFC: Support non-standard extension (call via casted function pointer)
- Authentication-results: sourceware.org; auth=none
- References: <CAFiYyc0fAj3Dq6SEySEf93_Fx0heK5nh9VRrY-u8VNDePyqYdw at mail dot gmail dot com> <1973325441 dot 1569987 dot 1453909202540 dot JavaMail dot yahoo at mail dot yahoo dot com>
On 27.01.2016 16:40, Thorsten Otto wrote:
> > We are trying to support ... 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.
> Yes, i did understand that. But you are trying to do that by hacking
> gcc's m68k backend. I still think that's the wrong place to fix.
The non-support of "direct call to a function with a (wrong) prototype
via a function pointer cast" on m68k is not caused by a general issue in
gcc (gcc tracks the return type of the function pointer used to call the
function), but because of a pecularity of the m68k backend (the backend
ignores the return type of the function pointer in certain
circumstances). I don't see how this can be catered for outside of the
The effect of the patch I posted is reducing the effect of the "return
pointer in both a0 and d0" hack, which interferes with the usual
decision of the return value register. We do agree that the way the
patch achieves this result is ugly and a better way has been proposed.