at it fits has precedence in ghc history (and thus ghc
either needs to stop lying or find a new lie that just happens to work),
I strongly disagree. In that case, ghc developers not "replace a lie
with a different lie", but replaced a lie "(empty parameter list)" with
the truth "(unknown parameter list)".
Regards,
Michael Karcher
rameter "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
On 27.01.2016 11:33, Richard Biener wrote:
> On Tue, Jan 26, 2016 at 9:54 PM, Michael Karcher
> wrote:
>> On 26.01.2016 21:47, Richard Biener wrote:
>>
>>> I would still prefer the more obvious approach of using the target hook
>>> transition.
>> I in
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.
Regards,
Michael Karcher
hc is broken, not gcc.
ghc does not fetch anything from any register. ghc generates C code that
is known to be non-conforming, and gcc decides what register to fetch from.
Regards,
Michael Karcher
here is consensus that this patch can be
accepted. I do not want the current patch committed as-is, I just posted
it to get the idea across and start discussion.
Regards,
Michael Karcher
if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func
> ...
> else if (POINTER_TYPE_P (valtype))
>...
> else
> ...
Looks good and clean to me, but I expect my patch to have the same effect.
Regards,
Michael Karcher
n if the called function is
known and declared as returning a pointer.
Regards,
Michael Karcher
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.
Regards,
Michael Karcher
>From 50c0af571f829e54cb3274c05d7be3da411
