[Bug 1843795] Re: 'mtfsf' instruction can clear FI incorrectly
** Changed in: qemu Status: Incomplete => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1843795 Title: 'mtfsf' instruction can clear FI incorrectly Status in QEMU: New Bug description: Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: -- fpscr.ll = 0x1fff; __builtin_mtfsf (0b, fpscr.d); fpscr.d = __builtin_mffs (); -- On POWER9 hardware: mffs: FPSCR = 0x77ff On qemu (git master; "-cpu POWER9"): -- $ ./mtfsf mffs: FPSCR = 0x7ffd -- Two differences: bit 52: "reserved", so maybe a "don't care" case bit 46: "FI" $ git log -1 master commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 Merge: 019217c 2531164 Author: Peter Maydell Date: Mon Sep 9 09:48:34 2019 +0100 I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ Test attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843795/+subscriptions
[Bug 1841491] Re: floating point emulation can fail to set FE_UNDERFLOW
Comment #5 suggested splitting the "float" issue to a separate bug, which was done some time ago (bug #1841592). I think this ticket can be closed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841491 Title: floating point emulation can fail to set FE_UNDERFLOW Status in QEMU: Confirmed Bug description: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841491/+subscriptions
Re: [PATCH v2] target/ppc: Fix for optimized vsl/vsr instructions
On 10/4/19 8:43 AM, Stefan Brankovic wrote: > In previous implementation, invocation of TCG shift function could request > shift of TCG variable by 64 bits when variable 'sh' is 0, which is not > supported in TCG (values can be shifted by 0 to 63 bits). This patch fixes > this by using two separate invocation of TCG shift functions, with maximum > shift amount of 32. > > Name of variable 'shifted' is changed to 'carry' so variable naming > is similar to old helper implementation. > > Variables 'avrA' and 'avrB' are replaced with variable 'avr'. > > Fixes: 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822 > Reported-by: Paul Clark Preferred: "Paul A. Clarke" (for historical consistency) > Reported-by: Mark Cave-Ayland > Suggested-by: Aleksandar Markovic > Signed-off-by: Stefan Brankovic Applying this patch on top of dce5a787c05fe1a3e54d92871cdeba2af6798e0d eliminated the failures that I reported in https://bugs.launchpad.net/qemu/+bug/1841990 associated with vsl/vsr. Tested-by: Paul A. Clarke PC
Re: Re: target/ppc: bug in optimised vsl/vsr implementation?
On 10/2/19 2:40 PM, Richard Henderson wrote: > On 10/2/19 10:38 AM, Alex Bennée wrote: >> Is the denbcdq instruction exposed in any standard float operations? >> Once this is fixed it would be worth adding a testcase (either ppc64 >> specific or multiarch) so protect it from regression in the future. > > Not standard float operations -- this is binary coded decimal stuff. > It would certainly be possible to write a ppc specific test case. In comment #9 in the bug (https://bugs.launchpad.net/qemu/+bug/1841990/comments/9), I note that the issue was produced in running the test suite for the Power Vector Library project (https://github.com/open-power-sdk/pveclib), which makes productive use of dcbenq. Maybe that could be adopted or adapted to suit? PC
Re: Re: target/ppc: bug in optimised vsl/vsr implementation?
On 9/28/19 5:17 PM, Aleksandar Markovic wrote: > Also, check on the hardware the behavior listed as 'undefined' for vsl/vsr > in the docs - even though it is tehnically irrelevant, I am courious > whether the old or the new (or none of them) solution match the hardware. There does appear to be some odd behavior when one strays into the undefined. For example: source vector: 0102030405060708090a0b0c0d0e0f10 shift vector: 01020101010101010101010101010101 after vsl: 020806080a0c0e10121416181a1c1e20 ...this appears to use the byte-respective shift values using vsr with that result and the same shift vector: after vsr: 0182030405060708090a0b0c0d0e0f10 I expected to get back a result matching the source vector, but somehow, an extra bit got set. It would probably take some more thorough investigation to map out the undefined behavior, but I doubt there's any value to that. PC
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
Reverted 4e6d0920e7547e6af4bbac5ffe9adfe6ea621822, and those 'vsl/vsr' tests now succeed. -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
`vsl` appears to be acting incorrectly as well, per the test
'vec_bcdsr':
=> 0x16e0 :vsl v0,v0,v1
(gdb) p $vr0.uint128
$21 = 0x10111213141516172021222324252650
(gdb) p $vr1.uint128
$22 = 0x0
(gdb) stepi
0x16e4 in vec_slq ()
1: x/i $pc each byte
=> 0x16e4 :xxlor vs0,vs32,vs32
(gdb) p $vr0.uint128
$23 = 0x10111213141516572021222324252650
=> 0x16e0 :vsl v0,v0,v1
(gdb) p $vr0.uint128
$21 = 0x10111213141516172021222324252650
(gdb) p $vr1.uint128
$22 = 0x0
(gdb) stepi
0x16e4 in vec_slq ()
1: x/i $pc
=> 0x16e4 :xxlor vs0,vs32,vs32
(gdb) p $vr0.uint128
$23 = 0x10111213141516172021222324252650
Note in the final result differs in the first nybble of the 8th MSB
('57' vs '17').
--
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
0x
0x000c
0x2208
$ ./test-denbcdq 1
0x0001
0x001c
0x22080001
$ ./test-denbcdq $(seq 0 99)
0x0064
0x100c
0x22080080
--
With "qemu-ppc64le -cpu power9"
--
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq
0x
0x000c
0x000c
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1
0x0001
0x001c
0x001c
$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100)
0x0064
0x100c
0x100c
--
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
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
The final failure is 'vsr' acting incorrectly, with basically the same issue as 'vsl'. -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
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 => 0x1698 : bcdsub. v0,v0,v1,0 (gdb) p $vr0.uint128 $3 = 0x999d (gdb) p $vr1.uint128 $4 = 0x1d (gdb) stepi (gdb) p $vr1.uint128 $5 = 0x1d hardware: 1: x/i $pc => 0x1698 : bcdsub. v0,v0,v1,0 (gdb) p $vr0.uint128 $2 = 0x999d (gdb) p $vr1.uint128 $3 = 0x1d (gdb) nexti (gdb) p $vr0.uint128 $4 = 0x998d -- QEMU 4.2+patches: => 0x1740 : bcdadd. v0,v0,v1,0 (gdb) p $vr0.uint128 $1 = 0xa999000c (gdb) p $vr1.uint128 $2 = 0xc (gdb) p $cr $4 = 0x24000242 (gdb) nexti (gdb) p $vr0.uint128 $5 = 0x (gdb) p $cr $6 = 0x24000212 hardware: => 0x1740 : bcdadd. v0,v0,v1,0 (gdb) p $vr0.uint128 $2 = 0xa999000c (gdb) p $vr1.uint128 $3 = 0xc (gdb) p $cr $4 = 0x24000442 (gdb) nexti (gdb) p $vr0.uint128 $5 = 0x999000c (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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
> Did you see the follow up email indicating the typo that I found in patch 6? I did, then forgot to include it in my build. I've included that change now... > Does that help any more tests to pass? I'm down from 22 failures to 8. -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Bug 1841990] Re: instruction 'denbcdq' misbehaving
I'm still trying to track down a BE system. Everything I have which is newer than POWER7 is LE, and POWER7 is not sufficient to run the test. The test suite that produced the problem is from https://github.com /open-power-sdk/pveclib. The good news is that with your (v1) changes, 275 tests no longer fail. 22 tests still fail, but I bet it is different issue(s). -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
Re: [PATCH 0/7] target/ppc: DFP fixes and improvements
Mark,
What tree / branch would these patches apply to? (I've tried qemu master,
dgibson master and ppc-for-4.2, or I'm doing something wrong.)
PC
On 9/24/19 10:35 AM, Mark Cave-Ayland wrote:
> This patchset fixes the DFP issue reported at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_qemu_-2Bbug_1841990&d=DwIDAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0emNUfh2Pr0wDtXKlYJSCQ&m=NtaEgUJhN3SbT5hKyyOdgnt5ArLSzDw2l22WvleDMmU&s=qIBW6IX8pu3ej_AJj-toJH8PmhrvgJaXDJgbg1tgbY8&e=
>
> caused by the change in FP register storage in commit ef96e3ae96 "target/ppc:
> move FP and VMX registers into aligned vsr register array" along with some
> further tidy-up/improvements.
>
> Patches 1 and 2 introduce get/set helper functions for reading and writing
> DFP even-odd register pairs (rather than accessing the register pointers
> directly) which then leads to the real fix in patch 3.
>
> Following on from this patches 4 to 6 change the struct PPC_DFP internal
> decimal representation from uint64[2] to ppc_vsr_t which enables us to use
> the existing VsrD() macro to access the correct elements regardless of host
> endian and remove the explicit HI_IDX and LO_IDX references.
>
> Finally patch 7 simplifies the calls to set_dfp{64,128}() in DFP macros
> which can now be generated directly by the preprocessor rather than requiring
> an explicit if() statement.
>
> Signed-off-by: Mark Cave-Ayland
>
>
> Mark Cave-Ayland (7):
> target/ppc: introduce get_dfp{64,128}() helper functions
> target/ppc: introduce set_dfp{64,128}() helper functions
> target/ppc: update {get,set}_dfp{64,128}() helper functions to
> read/write DFP numbers correctly
> target/ppc: introduce dfp_finalize_decimal{64,128}() helper functions
> target/ppc: change struct PPC_DFP decimal storage from uint64[2] to
> ppc_vsr_t
> target/ppc: use existing VsrD() macro to eliminate HI_IDX and LO_IDX
> from dfp_helper.c
> target/ppc: remove unnecessary if() around calls to set_dfp{64,128}()
> in DFP macros
>
> target/ppc/cpu.h| 1 +
> target/ppc/dfp_helper.c | 384
> target/ppc/helper.h | 2 +-
> 3 files changed, 193 insertions(+), 194 deletions(-)
>
Re: [Qemu-devel] [PATCH v2 2/2] ppc: Add support for 'mffsce' instruction
On 9/17/19 3:46 PM, Richard Henderson wrote: > On 9/16/19 1:02 PM, Paul A. Clarke wrote: >> From: "Paul A. Clarke" >> >> ISA 3.0B added a set of Floating-Point Status and Control Register (FPSCR) >> instructions: mffsce, mffscdrn, mffscdrni, mffscrn, mffscrni, mffsl. >> This patch adds support for 'mffsce' instruction. >> >> 'mffsce' is identical to 'mffs', except that it also clears the exception >> enable bits in the FPSCR. >> >> On CPUs without support for 'mffsce' (below ISA 3.0), the >> instruction will execute identically to 'mffs'. >> >> Signed-off-by: Paul A. Clarke >> --- >> v2: no changes. >> >> target/ppc/translate/fp-impl.inc.c | 30 ++ >> target/ppc/translate/fp-ops.inc.c | 2 ++ >> 2 files changed, 32 insertions(+) > > Didn't I already give a > Reviewed-by: Richard Henderson > > for this? You did. Sorry for the confusion. I wasn't sure whether to resend or not, given the dependence on the other patch and David said he would be waiting for the respin. PC
Re: [Qemu-devel] [PATCH v2 1/2] ppc: Add support for 'mffscrn', 'mffscrni' instructions
On 9/17/19 3:45 PM, Richard Henderson wrote:
> On 9/16/19 1:02 PM, Paul A. Clarke wrote:
>> +#define FP_DRN2 (1ull << FPSCR_DRN2)
>> +#define FP_DRN1 (1ull << FPSCR_DRN1)
>> +#define FP_DRN0 (1ull << FPSCR_DRN0)
>> +#define FP_DRN (FP_DRN2 | FP_DRN1 | FP_DRN0)
>
> Why not just 7ull << FPSCR_DRN?
> Are the individual DRN bits separately useful?
> They don't appear to be...
I was just following what was done with RN:
#define FPSCR_RN11
#define FPSCR_RN00 /* Floating-point rounding control */
...
#define FP_RN1 (1ull << FPSCR_RN1)
#define FP_RN0 (1ull << FPSCR_RN0)
#define FP_RN (FP_RN1 | FP_RN0)
>> -#define FP_MODE FP_RN
>> +#define FP_MODE (FP_DRN | FP_RN)
>
> This, I think, isn't helpful.
>
>> +static void gen_helper_mffscrn(DisasContext *ctx, TCGv_i64 t1)
>> +{
>> +TCGv_i64 t0 = tcg_temp_new_i64();
>> +TCGv_i32 mask = tcg_const_i32(0x0001);
>> +
>> +gen_reset_fpstatus();
>> +tcg_gen_extu_tl_i64(t0, cpu_fpscr);
>> +tcg_gen_andi_i64(t0, t0, FP_MODE | FP_ENABLES);
>> +set_fpr(rD(ctx->opcode), t0);
>> +
>> +/* Mask FPSCR value to clear RN. */
>> +tcg_gen_andi_i64(t0, t0, ~FP_MODE);
>
> Because here,
>
>> +static void gen_mffscrn(DisasContext *ctx)
>> +{
>> +TCGv_i64 t1;
>> +
>> +if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
>> +return gen_mffs(ctx);
>> +}
>> +
>> +if (unlikely(!ctx->fpu_enabled)) {
>> +gen_exception(ctx, POWERPC_EXCP_FPU);
>> +return;
>> +}
>> +
>> +t1 = tcg_temp_new_i64();
>> +get_fpr(t1, rB(ctx->opcode));
>> +/* Mask FRB to get just RN. */
>> +tcg_gen_andi_i64(t1, t1, FP_MODE);
>
> and here, we're only interested in RN, not DRN.
Oh, you're right, of course.
> Possibly FP_MODE should itself be removed. It's used
> exactly once, in mffsl, which could just as easily
> reference FP_RN | FP_DRN.
I will do, and then send an updated version.
PC
Re: [Qemu-devel] [PATCH] tests/tcg: add float_madds test to multiarch
On 9/13/19 8:49 AM, Alex Bennée wrote:
> +static float f32_numbers[] = {
> +-SNANF,
> +-NAN,
> +-INFINITY,
> +-FLT_MAX,
> +-1.111E+31,
> +-1.111E+30,
> +-1.08700982e-12,
> +-1.78051176e-20,
> +-FLT_MIN,
> +0.0,
> +FLT_MIN,
> +2.98023224e-08,
> +5.96046E-8, /* min positive FP16 subnormal */
> +6.09756E-5, /* max subnormal FP16 */
> +6.10352E-5, /* min positive normal FP16 */
> +1.0,
> +1.0009765625, /* smallest float after 1.0 FP16 */
> +2.0,
> +M_E, M_PI,
> +65503.0,
> +65504.0, /* max FP16 */
> +65505.0,
> +131007.0,
> +131008.0, /* max AFP */
> +131009.0,
> +1.111E+30,
> +FLT_MAX,
> +INFINITY,
> +NAN,
> +SNANF
> +};
I've noticed that Glibc prefers to use hex representation for float values, to
ensure an accurate representation. If you care to do so, here they are:
static float f32_numbers[] = {
-SNANF,
-NAN,
-INFINITY,
-FLT_MAX,
-0x1.1874b2p+103,
-0x1.c0bab6p+99,
-0x1.31f75p-40,
-0x1.505444p-66,
-FLT_MIN,
0.0,
FLT_MIN,
0x1p-25,
0x1.e6p-25, /* min positive FP16 subnormal */
0x1.ff801ap-15, /* max subnormal FP16 */
0x1.0cp-14, /* min positive normal FP16 */
1.0,
0x1.004p+0, /* smallest float after 1.0 FP16 */
2.0,
M_E, M_PI,
0x1.ffbep+15,
0x1.ffcp+15, /* max FP16 */
0x1.ffc2p+15,
0x1.ffbfp+16,
0x1.ffcp+16, /* max AFP */
0x1.ffc1p+16,
0x1.c0bab6p+99,
FLT_MAX,
INFINITY,
NAN,
SNANF
};
PC
[Qemu-devel] [Bug 1843795] [NEW] 'mtfsf' instruction can clear FI incorrectly
Public bug reported: Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: -- fpscr.ll = 0x1fff; __builtin_mtfsf (0b, fpscr.d); fpscr.d = __builtin_mffs (); -- On POWER9 hardware: mffs: FPSCR = 0x77ff On qemu (git master; "-cpu POWER9"): -- $ ./mtfsf mffs: FPSCR = 0x7ffd -- Two differences: bit 52: "reserved", so maybe a "don't care" case bit 46: "FI" $ git log -1 master commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 Merge: 019217c 2531164 Author: Peter Maydell Date: Mon Sep 9 09:48:34 2019 +0100 I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ Test attached. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "test case - mtfsf clears FI" https://bugs.launchpad.net/bugs/1843795/+attachment/5288363/+files/mtfsf.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1843795 Title: 'mtfsf' instruction can clear FI incorrectly Status in QEMU: New Bug description: Using mtfsf instruction can clear the FPSCR FI bit incorrectly. This code snippet exhibits the issue: -- fpscr.ll = 0x1fff; __builtin_mtfsf (0b, fpscr.d); fpscr.d = __builtin_mffs (); -- On POWER9 hardware: mffs: FPSCR = 0x77ff On qemu (git master; "-cpu POWER9"): -- $ ./mtfsf mffs: FPSCR = 0x7ffd -- Two differences: bit 52: "reserved", so maybe a "don't care" case bit 46: "FI" $ git log -1 master commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1 Merge: 019217c 2531164 Author: Peter Maydell Date: Mon Sep 9 09:48:34 2019 +0100 I tracked the clear is coming from do_float_check_status, likely the one in gen_mtfsf, but then I get lost figuring out what _should_ be happening. :-/ Test attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843795/+subscriptions
[Qemu-devel] [Bug 1841990] Re: instruction 'denbcdq' misbehaving
I have access to lots of Power hardware, and happy to test and help however I can! Thanks, Mark! -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Qemu-devel] [Bug 1841990] Re: instruction 'denbcdq' misbehaving
@Philippe, thank you for spending the time to find a compiler that works with the testcase. I've been operating on RHEL 8 primarily: gcc version 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC) -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
[Qemu-devel] [Bug 1841990] [NEW] instruction 'denbcdq' misbehaving
Public bug reported: 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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?) ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "test case for using denbcdq" https://bugs.launchpad.net/bugs/1841990/+attachment/5285701/+files/test-denbcdq.c -- 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 0x 0x000c 0x2208 $ ./test-denbcdq 1 0x0001 0x001c 0x22080001 $ ./test-denbcdq $(seq 0 99) 0x0064 0x100c 0x22080080 -- With "qemu-ppc64le -cpu power9" -- $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 0x 0x000c 0x000c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 0x0001 0x001c 0x001c $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) 0x0064 0x100c 0x100c -- 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
Re: [Qemu-devel] [Qemu-ppc] [PULL 41/49] target/ppc: improve VSX_FMADD with new GEN_VSX_HELPER_VSX_MADD macro
On 8/28/19 10:50 AM, Laurent Vivier wrote:
> On 02/07/2019 08:08, David Gibson wrote:
>> From: Mark Cave-Ayland
>>
>> Introduce a new GEN_VSX_HELPER_VSX_MADD macro for the generator function
>> which
>> enables the source and destination registers to be decoded at translation
>> time.
>>
>> This enables the determination of a or m form to be made at translation time
>> so
>> that a single helper function can now be used for both variants.
>>
>> Signed-off-by: Mark Cave-Ayland
>> Reviewed-by: Richard Henderson
>> Message-Id: <20190616123751.781-16-mark.cave-ayl...@ilande.co.uk>
>> Signed-off-by: David Gibson
>> ---
>> target/ppc/fpu_helper.c | 68
>> target/ppc/helper.h | 48 ++---
>> target/ppc/translate/vsx-impl.inc.c | 81 +
>> target/ppc/translate/vsx-ops.inc.c | 70 +
>> 4 files changed, 122 insertions(+), 145 deletions(-)
>>
>
> This patch breaks something with python/libm and RHEL8.
>
> # dnf update
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault (core dumped)
>
> # gdb
> ...
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x004000d09acc in __exp1 () from /lib64/libm.so.6
> Missing separate debuginfos, use: yum debuginfo-install
> platform-python-3.6.8-14.el8.ppc64le
> (gdb) bt
> #0 0x004000d09acc in __exp1 () from /lib64/libm.so.6
> #1 0x004000d0dcb4 in __pow_finite () from /lib64/libm.so.6
> #2 0x004000cd3c8c in powf64 () from /lib64/libm.so.6
> #3 0x0040009d5c5c in float_pow () from /lib64/libpython3.6m.so.1.0
>
> If I revert it, it works fine.
>
> My first guess is the opcode decoding is not correct to replace the afrm
> field.
>
> I'm not sure to understand correctly the code, but this seems to fix the
> problem:
>
> --- a/target/ppc/translate/vsx-impl.inc.c
> +++ b/target/ppc/translate/vsx-impl.inc.c
> @@ -1308,7 +1308,7 @@ static void gen_##name(DisasContext *ctx)
> \
> }
> \
> xt = gen_vsr_ptr(xT(ctx->opcode));
> \
> xa = gen_vsr_ptr(xA(ctx->opcode));
> \
> -if (ctx->opcode & PPC_BIT(25)) {
> \
> +if (ctx->opcode & PPC_BIT32(25)) {
> \
> /*
> \
> * AxT + B
> \
> */
> \
This same patch was just posted a week ago (by me).
https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg04344.html
David Gibson "Applied to ppc-for-4.2" the same day. Can you try that?
PC
[Qemu-devel] [Bug 1841592] Re: ppc: softfloat float implementation issues
-- ppc64le native: $ gcc -c -O2 ffma.c $ gcc -O2 test-ffma.c ffma.o -lm -o test-ffma $ ./test-ffma $(./test-ffma) ffma(0x1p-149, 0x1p-149, 0x1p-149) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-149 -- qemu-system-ppc64: $ ./test-ffma $(./test-ffma) ffma(0x1p-149, 0x1p-149, 0x1p-149) 0x0 0x200 FE_INEXACT 0x1p-149 ** Attachment added: "2nd file of float test case" https://bugs.launchpad.net/qemu/+bug/1841592/+attachment/5284931/+files/ffma.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841592 Title: ppc: softfloat float implementation issues Status in QEMU: New Bug description: Per bug #1841491, Richard Henderson (rth) said: > The float test failure is part of a larger problem for target/powerpc > in which all float routines are implemented incorrectly. They are all > implemented as double operations with rounding to float as a second > step. Which not only produces incorrect exceptions, as in this case, > but incorrect numerical results from the double rounding. > > This should probably be split to a separate bug... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841592/+subscriptions
[Qemu-devel] [Bug 1841592] [NEW] ppc: softfloat float implementation issues
Public bug reported: Per bug #1841491, Richard Henderson (rth) said: > The float test failure is part of a larger problem for target/powerpc > in which all float routines are implemented incorrectly. They are all > implemented as double operations with rounding to float as a second > step. Which not only produces incorrect exceptions, as in this case, > but incorrect numerical results from the double rounding. > > This should probably be split to a separate bug... ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "float test case" https://bugs.launchpad.net/bugs/1841592/+attachment/5284928/+files/test-ffma.c ** Description changed: Per bug #1841491, Richard Henderson (rth) said: - > The float test failure is part of a larger problem for target/powerpc in which all float - > routines are implemented incorrectly. They are all implemented as double operations with - > rounding to float as a second step. Which not only produces incorrect exceptions, as in - > this case, but incorrect > numerical results from the double rounding. - > + > The float test failure is part of a larger problem for target/powerpc + > in which all float routines are implemented incorrectly. They are all + > implemented as double operations with rounding to float as a second + > step. Which not only produces incorrect exceptions, as in this case, + > but incorrect > numerical results from the double rounding. + > > This should probably be split to a separate bug... ** Description changed: Per bug #1841491, Richard Henderson (rth) said: > The float test failure is part of a larger problem for target/powerpc > in which all float routines are implemented incorrectly. They are all > implemented as double operations with rounding to float as a second > step. Which not only produces incorrect exceptions, as in this case, - > but incorrect > numerical results from the double rounding. + > but incorrect numerical results from the double rounding. > > This should probably be split to a separate bug... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841592 Title: ppc: softfloat float implementation issues Status in QEMU: New Bug description: Per bug #1841491, Richard Henderson (rth) said: > The float test failure is part of a larger problem for target/powerpc > in which all float routines are implemented incorrectly. They are all > implemented as double operations with rounding to float as a second > step. Which not only produces incorrect exceptions, as in this case, > but incorrect numerical results from the double rounding. > > This should probably be split to a separate bug... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841592/+subscriptions
[Qemu-devel] [Bug 1841491] Re: floating point emulation can fail to set FE_UNDERFLOW
Responding to the patch https://lists.nongnu.org/archive/html/qemu- ppc/2019-08/msg00404.html, it seems to work for "double", but not for "float". Test case attached. ** Attachment added: "float testcase" https://bugs.launchpad.net/qemu/+bug/1841491/+attachment/5284810/+files/test-ffma.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841491 Title: floating point emulation can fail to set FE_UNDERFLOW Status in QEMU: New Bug description: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841491/+subscriptions
[Qemu-devel] [Bug 1841491] Re: floating point emulation can fail to set FE_UNDERFLOW
** Attachment added: "2nd file of float testcase" https://bugs.launchpad.net/qemu/+bug/1841491/+attachment/5284821/+files/ffma.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841491 Title: floating point emulation can fail to set FE_UNDERFLOW Status in QEMU: New Bug description: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841491/+subscriptions
Re: [Qemu-devel] [PATCH] target/ppc: Set float_tininess_before_rounding at cpu reset
On 8/26/19 9:00 PM, Richard Henderson wrote:
> As defined in Power 3.0 section 4.4.4 "Underflow Exception",
> a tiny result is detected before rounding.
Responded in the bug:
https://bugs.launchpad.net/qemu/+bug/1841491/comments/3
In my testing, this works for "double", but not "float".
> Fixes: https://bugs.launchpad.net/qemu/+bug/1841491
> Reported-by: Paul Clarke
> Signed-off-by: Richard Henderson
> ---
> target/ppc/translate_init.inc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
> index 4a21ed7289..023138c2f9 100644
> --- a/target/ppc/translate_init.inc.c
> +++ b/target/ppc/translate_init.inc.c
> @@ -10461,6 +10461,10 @@ static void ppc_cpu_reset(CPUState *s)
> s->exception_index = POWERPC_EXCP_NONE;
> env->error_code = 0;
>
> +/* tininess for underflow is detected before rounding */
> +set_float_detect_tininess(float_tininess_before_rounding,
> + &env->fp_status);
> +
> for (i = 0; i < ARRAY_SIZE(env->spr_cb); i++) {
> ppc_spr_t *spr = &env->spr_cb[i];
PC
[Qemu-devel] [Bug 1841491] Re: floating point emulation can fail to set FE_UNDERFLOW
** Attachment added: "2nd file of testcase" https://bugs.launchpad.net/qemu/+bug/1841491/+attachment/5284809/+files/fma.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841491 Title: floating point emulation can fail to set FE_UNDERFLOW Status in QEMU: New Bug description: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841491/+subscriptions
[Qemu-devel] [Bug 1841491] [NEW] floating point emulation can fail to set FE_UNDERFLOW
Public bug reported: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "testcase reporting exceptions set by simple floating point multiply-add" https://bugs.launchpad.net/bugs/1841491/+attachment/5284808/+files/test-fma.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841491 Title: floating point emulation can fail to set FE_UNDERFLOW Status in QEMU: New Bug description: Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. On ppc64le native: -- $ gcc -c -O2 fma.c $ gcc -O2 test-fma.c fma.o -lm -o test-fma $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x1p-1022 -- On qemu-system-ppc64: -- $ ./test-fma $(./test-fma) fma(0x1.cp-1022, 0x1.1p-1, 0x0.1p-1022) 0x0 0x200 FE_INEXACT 0x1p-1022 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841491/+subscriptions
Re: [Qemu-devel] [PATCH 1/1] target/ppc: Fix do_float_check_status vs inexact
On 8/26/19 11:54 AM, Richard Henderson wrote:
> The underflow and inexact exceptions are not mutually exclusive.
> Check for both of them. Tidy the reset of FPSCR[FI].
>
> Fixes: https://bugs.launchpad.net/bugs/1841442
> Reported-by: Paul Clarke
> Signed-off-by: Richard Henderson
Tested-by: Paul Clarke
Thanks, Richard!
There seems to be a similar problem with underflow. I'll narrow down a test
case, and I guess I'll just open a new bug report.
PC
> ---
> target/ppc/fpu_helper.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
> index 07bc9051b0..2e023c5204 100644
> --- a/target/ppc/fpu_helper.c
> +++ b/target/ppc/fpu_helper.c
> @@ -630,19 +630,15 @@ static void do_float_check_status(CPUPPCState *env,
> uintptr_t raddr)
> {
> CPUState *cs = env_cpu(env);
> int status = get_float_exception_flags(&env->fp_status);
> -bool inexact_happened = false;
>
> if (status & float_flag_overflow) {
> float_overflow_excp(env);
> } else if (status & float_flag_underflow) {
> float_underflow_excp(env);
> -} else if (status & float_flag_inexact) {
> -float_inexact_excp(env);
> -inexact_happened = true;
> }
> -
> -/* if the inexact flag was not set */
> -if (inexact_happened == false) {
> +if (status & float_flag_inexact) {
> +float_inexact_excp(env);
> +} else {
> env->fpscr &= ~(1 << FPSCR_FI); /* clear the FPSCR[FI] bit */
> }
>
>
[Qemu-devel] [Bug 1841442] Re: floating point emulation can fail to set FE_INEXACT
Interesting. Did you run qemu-aarch64 on aarch64? If so, it may have been using "hardfloat". I ran "qemu-system-ppc64" on x86_64 and "qemu- x86_64" on ppc64le to ensure I was using "softfloat". -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841442 Title: floating point emulation can fail to set FE_INEXACT Status in QEMU: New Bug description: Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. On ppc64le native: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- On x86_64: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x30 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- Using qemu-system-ppc64 -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x800 FE_UNDERFLOW 0x 0.00 -- Using qemu-x86_64: -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x0 0x 0.00 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841442/+subscriptions
[Qemu-devel] [Bug 1841442] [NEW] floating point emulation can fail to set FE_INEXACT
Public bug reported: Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. On ppc64le native: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- On x86_64: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x30 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- Using qemu-system-ppc64 -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x800 FE_UNDERFLOW 0x 0.00 -- Using qemu-x86_64: -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x0 0x 0.00 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "testcase reporting exceptions set by nextafter" https://bugs.launchpad.net/bugs/1841442/+attachment/5284718/+files/nextafter.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1841442 Title: floating point emulation can fail to set FE_INEXACT Status in QEMU: New Bug description: Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. On ppc64le native: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0xa00 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- On x86_64: -- $ gcc nextafter.c -o nextafter -lm $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x30 FE_INEXACT FE_UNDERFLOW 0x 0.00 -- Using qemu-system-ppc64 -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x800 FE_UNDERFLOW 0x 0.00 -- Using qemu-x86_64: -- $ ./nextafter $(./nextafter) 0x0001 0.00 0x0 0x0 0x 0.00 -- QEMU versions vary, but not too much, and are pretty close to git HEAD: - 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging - 864ab31 Update version for v4.1.0-rc4 release Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1841442/+subscriptions
Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Three floating point fixes
On 8/19/19 1:44 AM, Aleksandar Markovic wrote: > 19.08.2019. 08.30, "David Gibson" је > написао/ла: >> >> On Sun, Aug 18, 2019 at 10:59:01PM +0200, Aleksandar Markovic wrote: >>> 18.08.2019. 10.10, "Richard Henderson" је >>> написао/ла: On 8/16/19 11:59 PM, Aleksandar Markovic wrote: >> From: "Paul A. Clarke" ... >> ISA 3.0B has xscvdpspn leaving its result in word 1 of the target > register, >> and mffprwz expecting its input to come from word 0 of the source > register. >> This sequence fails with QEMU, as a shift is required between > those >>> two >> instructions. However, the hardware splats the result to both > word 0 > and >> word 1 of its output register, so the shift is not necessary. >> Expect a future revision of the ISA to specify this behavior. >> > > Hmmm... Isn't this a gcc bug (using undocumented hardware feature), >>> given > everything you said here? The key here is "expect a future revision of the ISA to specify this >>> behavior". It's clearly within IBM's purview to adjust the specification to > document >>> a previously undocumented hardware feature. >>> >>> By no means, yes, the key is in ISA documentation. But, the impression > that >>> full original commit message conveys is that the main reason for change > is >>> gcc behavior. If we accepted in general that gcc behavior determines > QEMU >>> behavior, I am afraid we would be on a very slippery slope - therefore I >>> think the commit message (and possible code comment) should, in my > opinion, >>> mention ISA docs as the central reason for change. Paul, is there any >>> tentative release date of the new ISA specification? >> >> It's not really a question of gcc behaviour, it's a question of actual >> cpu behaviour versus ISA document. Which one qemu should follow is >> somewhat debatable, but it sounds here like the ISA will be updated to >> match the cpu, which weights it heavily in favour of mimicing the >> actual cpu. >> > > This sounds right to me. Thanks for the reviews and great discussion. While not yet part of a published version of the ISA, I did find the behavior documented in the User's Manuals for the POWER8 and POWER9 processors: https://www-355.ibm.com/systems/power/openpower/ "Public Documents" - "POWER9 Processor User's Manual" - "POWER8 Processor User's Manual for the SCM" POWER9 Processor User's Manual 4. Power Architecture Compliance 4.3 Floating-Point Processor (FP, VMX, and VSX) 4.3.7 Floating-Point Invalid Forms and Undefined Conditions POWER8 Processor User's Manual for the Single-Chip Module 3. Power Architecture Compliance 3.2 Floating-Point Processor (FP, VMX, and VSX) 3.2.9 Floating-Point Invalid Forms and Undefined Conditions In a bullet: - VSX scalar convert from double-precision to single-precision (xscvdpsp, xscvdpspn). VSR[32:63] is set to VSR[0:31]. I have not confirmed when the new revision of the ISA will be published, but it's on somebody's "to do" list. I will respin the patch as 3 independent patches, and include a reference to the above documents for the change under discussion here. (The other two changes may take a bit more time, because like David, I find the FPU emulation code cryptic. :-/ ) These issues were found while running Glibc's test suite for "math", and there are still a *LOT* of QEMU-only FAILs, so I may be back again with suggested fixes or questions. :-) PC
Re: [Qemu-devel] [PATCH v3] ppc: Add support for 'mffsl' instruction
Should these 'checkpatch' ERRORs be addressed, even if it will diverge the code
style from the existing, surrounding code?
On 8/14/19 11:30 AM, no-re...@patchew.org wrote:
> This series seems to have some coding style problems. See output below for
> more information:
> === OUTPUT BEGIN ===
> ERROR: code indent should never use tabs
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl", XRA(63,583,12), XRARB_MASK,^IPOWER9,^I{ FRT } },$
>
> ERROR: space required after that ',' (ctx:VxV)
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl", XRA(63,583,12), XRARB_MASK, POWER9, { FRT } },
> ^
>
> ERROR: space required after that ',' (ctx:VxV)
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl", XRA(63,583,12), XRARB_MASK, POWER9, { FRT } },
> ^
>
> ERROR: braces {} are necessary for all arms of this statement
> #148: FILE: target/ppc/translate/fp-impl.inc.c:625:
> +if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300)))
> [...]
>
> total: 4 errors, 0 warnings, 115 lines checked
>
> Commit c51c0f894525 (ppc: Add support for 'mffsl' instruction) has style
> problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> === OUTPUT END ===
PC
