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
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
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
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
ed return type), I expect ghc develepors to happily
use it.
Regards,
Michael Karcher
On 26.01.2016 10:42, Andreas Schwab wrote:
> Michael Karcher writes:
>> ghc does not have the information yet when it writes the
>> declaration.
> It knows it when it calls the function, so that's a lame excuse.
The excuse is not as lame as it sounds at the first sight
n if the called function is
known and declared as returning a pointer.
Regards,
Michael Karcher
On 26.01.2016 00:39, Andreas Schwab wrote:
> Michael Karcher writes:
>
>> *can't* (forward-)declare a function without fixing the return type.
> What does "fixing the return type" mean in the context of lying to the
> compiler?
OK, now I get your question. I don&#
On 25.01.2016 23:07, Andreas Schwab wrote:
> Michael Karcher writes:
>> but it fixes the return type to some pointer type.
> Why does it do that?
Please help me understand why the sentence before the sentence you
quoted is not an answer to your question:
| This is because its inter
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
/X-Surf-100 and
http://wiki.icomp.de/wiki/RapidRoad.
Regards,
Michael Karcher
d" approach, *like* you are using for other drivers, I got your point
and you are likely right.
>> +static struct zorro_device_id xsurf100_zorro_tbl[] = {
> const
Of course. Thanks for pointing it out.
BTW: for me, the patch-set was trivially forward-ported by git rebasing
to 4.4-rc1
Kind regards,
Michael Karcher
r the problem at hand.
"m68k: Make sys_atomic_cmpxchg_32 work on classic m68k"
It has been introduced between Linux 3.2.26 and 3.2.27 into the stable
series, and between 3.5-rc1 and 3.5-rc2 into the development kernel.
Regards,
Michael Karcher
signature.asc
Description: This is a digitally signed message part
16 matches
Mail list logo
