[Bug 1841990] Re: instruction 'denbcdq' misbehaving

[Paul Clarke <pc@us.ibm.com>]

I haven't tried QEMU 3.1 yet.  Adding to to-do list.

I am narrowing down the remaining failures.  Within the pveclib test suite, there are two tests, one is failing, "pveclib_test".  It contains numerous subtests.  The failing subtests are:
- test_setb_bcdsq
- test_setb_bcdinv
- test_bcdsr
- test_bcdsrrqi

Investigating the first two so far, it looks like "bcdadd." and
"bcdsub." are not operating correctly.  gdb sessions showing the
difference in behavior between QEMU 4.2+patches and hardware (in that
order):

QEMU 4.2+patches:

(gdb) x/i $pc                                                                                                       
=> 0x10000698 <vec_setbool_bcdsq+60>:   bcdsub. v0,v0,v1,0                                                          
(gdb) p $vr0.uint128                                                                                                
$3 = 0x9999999999999999999999999999999d                                                                             
(gdb) p $vr1.uint128                                                                                                
$4 = 0x1d                                                                                                           
(gdb) stepi                                                                                                         
(gdb) p $vr1.uint128                                                                                                
$5 = 0x1d

hardware:

1: x/i $pc
=> 0x10000698 <vec_setbool_bcdsq+60>:	bcdsub. v0,v0,v1,0
(gdb) p $vr0.uint128
$2 = 0x9999999999999999999999999999999d
(gdb) p $vr1.uint128
$3 = 0x1d
(gdb) nexti
(gdb) p $vr0.uint128
$4 = 0x9999999999999999999999999999998d

--

QEMU 4.2+patches:

=> 0x10000740 <vec_setbool_bcdinv+60>:  bcdadd. v0,v0,v1,0
(gdb) p $vr0.uint128                                      
$1 = 0xa999999999999999000000000000000c                   
(gdb) p $vr1.uint128                                      
$2 = 0xc                                                  
(gdb) p $cr                                               
$4 = 0x24000242                                           
(gdb) nexti                                               
(gdb) p $vr0.uint128                                      
$5 = 0xffffffffffffffffffffffffffffffff                   
(gdb) p $cr                             
$6 = 0x24000212                         

hardware:

=> 0x10000740 <vec_setbool_bcdinv+60>:  bcdadd. v0,v0,v1,0
(gdb) p $vr0.uint128
$2 = 0xa999999999999999000000000000000c
(gdb) p $vr1.uint128
$3 = 0xc
(gdb) p $cr
$4 = 0x24000442
(gdb) nexti
(gdb) p $vr0.uint128
$5 = 0x999999999999999000000000000000c
(gdb) p $cr
$6 = 0x24000412

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841990

Title:
  instruction 'denbcdq' misbehaving

Status in QEMU:
  New

Bug description:
  Instruction 'denbcdq' appears to have no effect.  Test case attached.

  On ppc64le native:
  --
  gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq
  $ ./test-denbcdq
  0x00000000000000000000000000000000
  0x0000000000000000000000000000000c
  0x22080000000000000000000000000000
  $ ./test-denbcdq 1
  0x00000000000000000000000000000001
  0x0000000000000000000000000000001c
  0x22080000000000000000000000000001
  $ ./test-denbcdq $(seq 0 99)
  0x00000000000000000000000000000064
  0x0000000000000000000000000000100c
  0x22080000000000000000000000000080
  --

  With "qemu-ppc64le -cpu power9"
  --
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq
  0x00000000000000000000000000000000
  0x0000000000000000000000000000000c
  0x0000000000000000000000000000000c
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1
  0x00000000000000000000000000000001
  0x0000000000000000000000000000001c
  0x0000000000000000000000000000001c
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100)
  0x00000000000000000000000000000064
  0x0000000000000000000000000000100c
  0x0000000000000000000000000000100c
  --

  I started looking at the code, but I got confused rather quickly.
  Could be related to endianness? I think denbcdq arrived on the scene
  before little-endian was a big deal.  Maybe something to do with
  utilizing implicit floating-point register pairs...  I don't think the
  right data is getting to helper_denbcdq, which would point back to the
  gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc).  (Maybe?)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1841990/+subscriptions