On 27.01.2016 22:49, Andrew Pinski wrote: > On Wed, Jan 27, 2016 at 7:17 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> >> We are trying to support >> >> t.c >> --- >> void *foo(); >> >> int bar() >> { >> return ((int (*)())foo) (); >> } > Why can't ghc produce code like: > int bar () > { > int (*foo1)() = foo; > asm("":"+r"(foo1)); > return foo1(); > } 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 anyway. 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 to ghc. > Thanks, > Andrew Regards, Michael Karcher