** 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
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.
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
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
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
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
`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
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
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
-
> 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
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
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
>
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
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)
>
>
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,
> +
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
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
@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.
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
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.
>>
>>
-- 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
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
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
--
** 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:
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_ini
** 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
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
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
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
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
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:
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 ===
>
32 matches
Mail list logo
