Re: [PATCH] ppc: Fix 'calli' when floating-point arguments are passed

[Paul Cercueil]

Actually I think my calli() fix is wrong...

I swear the 2to3 check was passing before (with the exact same patch I 
sent) and now it decided to fail again.

I think it's because I added an instruction before the BL(d), so the 
value of "d" is outdated. The calculation of "d" should probably be:
d = (i0 - _jit->pc.w - !!varargs * 4) & ~3;

With this changed the 2to3 check works again here.

As for the SQRT, with the following simplified test:

---
#include "alu.inc"

.code
prolog
#define SQRT(N, T, I, V) FUN1(N, T, sqrt, I, V, f0, f1)
 SQRT(0, _f, -0.0, 0.0)

prepare
 pushargi ok
 ellipsis
finishi @printf
ret
epilog
---

I get:

paul@frank:~/dev/lightning$ check/lightning -v check/fop_sqrt.tst
       0x3f680000 mflr r0
       0x3f680004 stw r0,4(r1)
       0x3f680008 stw r14,-72(r1)
       0x3f68000c stfd f14,-80(r1)
       0x3f680010 stfd f15,-88(r1)
       0x3f680014 stw r31,-4(r1)
       0x3f680018 mr r31,r1
       0x3f68001c stwu r1,-160(r1)
       0x3f680020 lis r14,16232
       0x3f680024 lfs f15,4116(r14)
       0x3f680028 fsqrts f14,f15
       0x3f68002c lis r14,16232
       0x3f680030 lfs f0,4120(r14)
       0x3f680034 fcmpo cr0,f14,f0
       0x3f680038 beq 0x3f680040 :check/fop_sqrt.tst:7
       0x3f68003c bl 0x3f2b75f0
# :check/fop_sqrt.tst:7
       0x3f680040 lis r14,16232
       0x3f680044 lfs f14,4116(r14)
       0x3f680048 fsqrts f14,f14
       0x3f68004c lis r14,16232
       0x3f680050 lfs f0,4120(r14)
       0x3f680054 fcmpo cr0,f14,f0
       0x3f680058 beq 0x3f680060 :check/fop_sqrt.tst:7
       0x3f68005c bl 0x3f2b75f0
       0x3f680060 lis r14,16232
       0x3f680064 lfs f14,4116(r14)
       0x3f680068 fsqrts f15,f14
       0x3f68006c lis r14,16232
       0x3f680070 lfs f0,4120(r14)
       0x3f680074 fcmpo cr0,f15,f0
       0x3f680078 beq 0x3f680080 :check/fop_sqrt.tst:7
       0x3f68007c bl 0x3f2b75f0
       0x3f680080 lis r14,16232
       0x3f680084 lfs f15,4116(r14)
       0x3f680088 fsqrts f15,f15
       0x3f68008c lis r14,16232
       0x3f680090 lfs f0,4120(r14)
       0x3f680094 fcmpo cr0,f15,f0
       0x3f680098 beq 0x3f6800a0 :check/fop_sqrt.tst:7
       0x3f68009c bl 0x3f2b75f0
       0x3f6800a0 lis r3,16388
       0x3f6800a4 ori r3,r3,20992
       0x3f6800a8 bl 0x3f2ee17c
       0x3f6800ac addi r1,r1,160
       0x3f6800b0 lwz r0,4(r1)
       0x3f6800b4 lwz r14,-72(r1)
       0x3f6800b8 lfd f14,-80(r1)
       0x3f6800bc lfd f15,-88(r1)
       0x3f6800c0 mtlr r0
       0x3f6800c4 lwz r31,-4(r1)
       0x3f6800c8 blr
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - -
qemu: uncaught target signal 4 (Illegal instruction) - core dumped


Cheers,
-Paul



Le mar., août 23 2022 at 12:45:51 -0300, Paulo César Pereira de 
Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
> Em ter., 23 de ago. de 2022 às 12:31, Paul Cercueil
> <paul@crapouillou.net> escreveu:
> >  Note that this patch fixes the 3to2 and varargs checks, but the
> >  following are still failing: cvt, fop_sqrt, clobber, call.
>
>   Let's first check the most likely cause. For fop_sqrt.tst, please
> test commenting with // or /* */ the lines that have either $NaN
> or $Inf.
>   Also in the first suspect, clobber.tst might be failing at:
>          jmpf(__LINE__, unord,       0, $(0.0 / 0.0))
> but please test bisecting the tests, until finding the one that fails.
> It must be calling abort, running in a debugger would be a bit
> easier to debug.
>
>   For call.tst, please also bisect to find what test is failing. This
> test does extensive checking on to/from float/double tests, and
> to/from float/double/word tests as well as several validations on
> special values, for 32 bit, values like 0x80000000, 0xffffffff,
> 0x7fffffff, 0x80000001 and the similar 8 and 16 bit values, to
> check for proper conversions.
>
>   It must be something simple like the patch you just did, or
> might be a qemu-user bug.
>
> >  Cheers,
> >  -Paul
>
> Thanks,
> Paulo