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: Jeff Law <law at redhat dot com>
- To: Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>, Andrew Pinski <pinskia at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: Thorsten Otto <halgara at yahoo 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: Fri, 29 Jan 2016 21:13:48 -0700
- 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> <CA+=Sn1m026Ub4TPgSFsriUwPiigVZFos6PzN_hKhO0=6MQskPA at mail dot gmail dot com> <56A93F9B dot 7000108 at mkarcher dot dialup dot fu-berlin dot de>
On 01/27/2016 03:07 PM, Michael Karcher wrote:
Just a few clarifications. It's not specific to GCC; GCC's extended ASM
syntax has been supported by various other compilers for some time.
Why can't ghc produce code like:
int bar ()
int (*foo1)() = foo;
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm language (as
would be needed to avoid lying about the type of foo).
Yes it no longer produces an direct function call but it might be
better in the long run anyways.
I don't really care about the direct function call. Using ghc on a
target where it can't generate native machine code is doomed to be slow
But I don't see how it "might be better in the long rung anyway". The
first thing I note is that this workaround is specific to gcc. I didn't
check the gcc internals manual, but I am unsure whether the constraint
"r" is portable to be used on function pointers on all architectures gcc
supports. Furthermore, this hides the fact that the use case is not
supported by playing games with the optimizer, whereas Jeff and Richard
try to get this use case supported.
If gcc decides that the m68k backend should not be adjusted to use the
parameter "valtype" to determine the register used by the currently
selected ABI for the return value on caller side, but keep using the
function declaration for that, I will nevertheless propose this change
"r" essentially says put the value into a general purpose register; I'm
not aware of any target where that would not work.
Anyway, right now our focus is the upcoming gcc-6 release. Attacking
this problem in GCC is queued for gcc-7 development.