Re: [Qemu-devel] undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)

On Fri, 5 Jun 2015, Paolo Bonzini wrote: The GCC manual says GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed '' as undefined, but this is subject to change. It would certainly be nice if they removed the this is subject to change part. The correct

Re: [Qemu-devel] [PATCH] tcg: increase MAX_OP_PER_INSTR to 395

On Fri, 23 Sep 2016, Richard Henderson wrote: > While increasing the max per insn is indeed one way to approach this, aarch64 > is being remarkably inefficient in this case. With the following, I see a > reduction from 387 ops to 261 ops; for a 64-bit host, the reduction is from > 258 ops to 195

[Qemu-devel] [PATCH] tcg: increase MAX_OP_PER_INSTR to 395

in a higher figure (or maybe a higher figure would be safer anyway). Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/tcg/tcg.h b/tcg/tcg.h index c9949aa..a7fa452 100644 --- a/tcg/tcg.h +++ b/tcg/tcg.h @@ -32,7 +32,7 @@ #include "tcg-target.h" /* XXX: make

Re: [Qemu-devel] [PATCH] tcg: increase MAX_OP_PER_INSTR to 395

On Fri, 23 Sep 2016, Laurent Desnogues wrote: > Hello, > > On Fri, Sep 23, 2016 at 1:53 AM, Joseph Myers <jos...@codesourcery.com> wrote: > > MAX_OP_PER_INSTR is currently 266, reported in commit > > 14dcdac82f398cbac874c8579b9583fab31c67bf to be the worst case

[Qemu-devel] [PATCH] tcg: correct 32-bit tcg_gen_ld8s_i64 sign-extension

of the uninitialized high part (in some GCC tests of AArch64 NEON shift intrinsics, in particular). This patch corrects the sign-extension logic, making it match other functions such as tcg_gen_ld16s_i64. Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/tcg/tcg-op.c b/t

[Qemu-devel] [PATCH] target/i386: fix pcmpxstrx substring search

correspond with the proper instruction semantics. This fixes four gcc test failures in my GCC 6-based testing. Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h index 16509d0..9f1b351 100644 --- a/target/i386/ops_sse.h +

[Qemu-devel] [PATCH] target/i386: fix phminposuw in-place operation

copied first. This fixes one gcc test failure in my GCC 6-based testing (and so concludes the present sequence of patches, as I don't have any further gcc test failures left in that testing that I attribute to QEMU bugs). Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/

[Qemu-devel] [PATCH] target/i386: set rip_offset for further SSE instructions

failures in my GCC 6-based testing. (I do not know whether there might be still further classes of instructions missing this setting.) Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/target/i386/translate.c b/target/i386/translate.c index 5fdadf9..95f7261

[Qemu-devel] [PATCH] target/i386: set rip_offset for some SSE4.1 instructions

the required rip_offset setting for those instructions, so fixing some GCC test failures (13 in the gcc testsuite in my GCC 6-based testing) when testing with a default CPU setting enabling those instructions. Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/targe

[Qemu-devel] [PATCH] target/i386: fix pmovsx/pmovzx in-place operations

-based testing) when testing with a default CPU setting enabling those instructions. Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h index 16509d0..d578216 100644 --- a/target/i386/ops_sse.h +++ b/target/i386/ops

[Qemu-devel] [PATCH] target/i386: fix packusdw in-place operation

by computing the result in a local temporary and copying it to the destination at the end; this patch fixes the packusdw helper to do likewise. This fixes three gcc test failures in my GCC 6-based testing. Signed-off-by: Joseph Myers <jos...@codesourcery.com> --- diff --git a/target/i386/ops_s

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

On Fri, 28 Dec 2018, Adhemerval Zanella wrote: > >> Currently we only have nios2 and csky (unfortunately). But since generic > >> definition for off_t and off64_t still assumes non-LFS support, all new > >> 32-bits ports potentially might carry the issue. > > > > For csky, we could still

[PATCH 2/4] softfloat: fix floatx80 pseudo-denormal addition / subtraction

or both values are pseudo-denormals (biased exponent zero, explicit integer bit 1). Add a check for that case, so making the results match those seen on x86 hardware for pseudo-denormals. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fpu

[PATCH 3/4] softfloat: fix floatx80 pseudo-denormal comparisons

, not the other more specific comparison operations. That is the only comparison function for floatx80 used in the i386 port, which is the only supported port with these pseudo-denormal semantics. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 4/4] softfloat: fix floatx80 pseudo-denormal round to integer

round to +/- 1 depending on the rounding mode) as hardware does. Fix this check (simplifying the code in the process). Signed-off-by: Joseph Myers --- fpu/softfloat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 8e9c714e6f..e29b07542a

[PATCH 0/4] softfloat: fix floatx80 emulation bugs

0). Joseph Myers (4): softfloat: silence sNaN for conversions to/from floatx80 softfloat: fix floatx80 pseudo-denormal addition / subtraction softfloat: fix floatx80 pseudo-denormal comparisons softfloat: fix floatx80 pseudo-denormal round to integer fpu/softfloat.c | 37

[PATCH 1/4] softfloat: silence sNaN for conversions to/from floatx80

Conversions between IEEE floating-point formats should convert signaling NaNs to quiet NaNs. Most of those in QEMU's softfloat code do so, but those for floatx80 fail to. Fix those conversions to silence signaling NaNs as well. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 24

Re: [PATCH 2/4] softfloat: fix floatx80 pseudo-denormal addition / subtraction

On Fri, 1 May 2020, Alex Bennée wrote: > > Joseph Myers writes: > > > The softfloat function addFloatx80Sigs, used for addition of values > > with the same sign and subtraction of values with opposite sign, fails > > to handle the case where the two values bot

Re: [PATCH 3/4] softfloat: fix floatx80 pseudo-denormal comparisons

On Fri, 1 May 2020, Alex Bennée wrote: > > Joseph Myers writes: > > > The softfloat floatx80 comparisons fail to allow for pseudo-denormals, > > which should compare equal to corresponding values with biased > > exponent 1 rather than 0. Add an adjustment for t

Re: [PATCH 3/4] softfloat: fix floatx80 pseudo-denormal comparisons

On Fri, 1 May 2020, Alex Bennée wrote: > OK - so these only turn up in i386? Patch 1, silencing sNaN, is about generic semantics of IEEE floating-point conversions (which are implemented correctly in various other cases in QEMU), and would be equally applicable to m68k (I believe, without

[PATCH v2 0/4] softfloat: fix floatx80 emulation bugs

but not enabled fail for unrelated reasons if enabled for floatx80, this does not do anything regarding enabling such tests. Joseph Myers (4): softfloat: silence sNaN for conversions to/from floatx80 softfloat: fix floatx80 pseudo-denormal addition / subtraction softfloat: fix floatx80 pseudo-denormal

[PATCH v2 3/4] softfloat: fix floatx80 pseudo-denormal comparisons

, not the other more specific comparison operations. That is the only comparison function for floatx80 used in the i386 port, which is the only supported port with these pseudo-denormal semantics. Signed-off-by: Joseph Myers --- fpu/softfloat.c| 5 + tests/tcg/i386

[PATCH v2 1/4] softfloat: silence sNaN for conversions to/from floatx80

Conversions between IEEE floating-point formats should convert signaling NaNs to quiet NaNs. Most of those in QEMU's softfloat code do so, but those for floatx80 fail to. Fix those conversions to silence signaling NaNs as well. Signed-off-by: Joseph Myers --- fpu/softfloat.c

[PATCH v2 4/4] softfloat: fix floatx80 pseudo-denormal round to integer

round to +/- 1 depending on the rounding mode) as hardware does. Fix this check (simplifying the code in the process). Signed-off-by: Joseph Myers --- fpu/softfloat.c| 2 +- tests/tcg/i386/test-i386-pseudo-denormal.c | 10 ++ 2 files changed, 11 insertions(+), 1

[PATCH v2 2/4] softfloat: fix floatx80 pseudo-denormal addition / subtraction

or both values are pseudo-denormals (biased exponent zero, explicit integer bit 1). Add a check for that case, so making the results match those seen on x86 hardware for pseudo-denormals. Signed-off-by: Joseph Myers --- fpu/softfloat.c| 6 ++ tests/tcg/i386/test-i386

[PATCH 4/5] target/i386: fix fscale handling of infinite exponents

signed exact zero or infinity as a result. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 22 ++ tests/tcg/i386/test-i386-fscale.c | 29 + 2 files changed, 51 insertions(+) diff --git a/target/i386/fpu_helper.c b/target/i386

[PATCH 2/5] target/i386: fix fscale handling of signaling NaN

The implementation of the fscale instruction returns a NaN exponent unchanged. Fix it to return a quiet NaN when the provided exponent is a signaling NaN. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 4 tests/tcg/i386/test-i386-fscale.c | 37

[PATCH 3/5] target/i386: fix fscale handling of invalid exponent encodings

. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 5 - tests/tcg/i386/test-i386-fscale.c | 29 + 2 files changed, 33 insertions(+), 1 deletion(-) diff --git a/target/i386/fpu_helper.c b/target/i386/fpu_helper.c index 60012c405c..7709af8fdd 100644

[PATCH 5/5] target/i386: fix fscale handling of rounding precision

precision, and fscale is not in that set. Fix the implementation to save and restore the rounding precision around the call to floatx80_scalbn. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 3 +++ tests/tcg/i386/test-i386-fscale.c | 13 + 2 files changed, 16 insertions

[PATCH 1/5] target/i386: implement special cases for fxtract

The implementation of the fxtract instruction treats all nonzero operands as normal numbers, so yielding incorrect results for invalid formats, infinities, NaNs and subnormal and pseudo-denormal operands. Implement appropriate handling of all those cases. Signed-off-by: Joseph Myers --- target

[PATCH 0/5] target/i386: fxtract, fscale fixes

result in spurious exceptions being set from a naive propagation of exceptions from the softfloat state, and thus will need updating to avoid propagating inappropriate exceptions when such propagation is implemented.) Joseph Myers (5): target/i386: implement special cases for fxtract target

[PATCH 4/4] target/i386: fix fbstp handling of out-of-range values

the softfloat code, which are large enough to be considered as out-of-range by this code) and storing the packed BCD indefinite encoding in that case. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 10 +++ tests/tcg/i386/test-i386-fbstp.c | 115

[PATCH 2/4] target/i386: fix fxam handling of invalid encodings

and C3 cleared) for invalid encodings. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c| 4 +- tests/tcg/i386/test-i386-fxam.c | 143 2 files changed, 145 insertions(+), 2 deletions(-) create mode 100644 tests/tcg/i386/test-i386-fxam.c diff --git

[PATCH 3/4] target/i386: fix fbstp handling of negative zero

The fbstp implementation stores +0 when the rounded result should be -0 because it compares an integer value with 0 to determine the sign. Fix this by checking the sign bit of the operand instead. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 5 - tests/tcg/i386/test

[PATCH 1/4] target/i386: fix floating-point load-constant rounding

setting "inexact") as specified. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 54 +++- tests/tcg/i386/test-i386-fldcst.c | 199 ++ 2 files changed, 248 insertions(+), 5 deletions(-) create mode 100644 tests/tcg/i386/test-i38

[PATCH 0/4] target/i386: miscellaneous x87 fixes

eptions even when it adds code to set exceptions in the softfloat state. Joseph Myers (4): target/i386: fix floating-point load-constant rounding target/i386: fix fxam handling of invalid encodings target/i386: fix fbstp handling of negative zero target/i386: fix fbstp handling of out-of-

[PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raising

rrying out the operation, is conservatively safe. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 126 +++- tests/tcg/i386/test-i386-fp-exceptions.c | 831 +++ 2 files changed, 926 insertions(+), 31 deletions(-) create mode 100644 tests/tcg/i386/te

[PATCH 1/2] target/i386: fix fisttpl, fisttpll handling of out-of-range values

-off-by: Joseph Myers --- target/i386/fpu_helper.c | 28 - tests/tcg/i386/test-i386-fisttp.c | 100 ++ 2 files changed, 126 insertions(+), 2 deletions(-) create mode 100644 tests/tcg/i386/test-i386-fisttp.c diff --git a/target/i386/fpu_helper.c b

[PATCH 0/2] target/i386: x87 exceptions fixes

exceptions for which traps are enabled (where there are many different bugs in the current implementation in QEMU). Joseph Myers (2): target/i386: fix fisttpl, fisttpll handling of out-of-range values target/i386: fix IEEE x87 floating-point exception raising target/i386/fp

Ping Re: [PATCH 0/5] target/i386: fxtract, fscale fixes

Ping for this patch series . Although my three patch series so far for floatx80 and i386 floating-point instructions fixes are independent of each other, it's likely future patch series in this area will depend on some of the

Re: [PATCH 0/4] target/i386: miscellaneous x87 fixes

On Thu, 14 May 2020, no-re...@patchew.org wrote: > This series seems to have some coding style problems. See output below for > more information: These are all false positives for the same reasons as for the previous patch series. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 0/5] target/i386: fxtract, fscale fixes

On Thu, 7 May 2020, no-re...@patchew.org wrote: > === OUTPUT BEGIN === > 1/5 Checking commit 69eed0bcaaaf (target/i386: implement special cases for > fxtract) > WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? I don't think any MAINTAINERS update is needed for a new

Re: [PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raising

On Tue, 19 May 2020, Richard Henderson wrote: > > Note that another bug in the x87 emulation is the lack of setting C1 for > > most instructions with inexact results based on the direction of rounding > > (which will require a new feature to be added to the softfloat code to > > record that

Re: [PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raising

On Tue, 19 May 2020, Richard Henderson wrote: > To retain the hard float fast path, we need to leave float_flag_invalid set > when the accrued exception bit is set. To me this suggests keep all of the > FPUS_* bits in fp_status and only convert to FPUS_* when we read the fp status > word. There

[PATCH] target/i386: correct fix for pcmpxstrx substring search

yte operand (that is, the case that would be broken by a simple revert of the non-empty-string part of my 2017 patch). Signed-off-by: Joseph Myers --- target/i386/ops_sse.h| 4 ++-- tests/tcg/i386/Makefile.target | 3 +++ tests/tcg/i386/test-i386-pcmpistri.c | 33 +++

Re: [PATCH 1/4] softfloat: silence sNaN for conversions to/from floatx80

On Fri, 1 May 2020, Alex Bennée wrote: > I still see some failures for: > > f64_to_extF80 > f128_to_extF80 Running what I think are those tests, I see e.g. ./fp-test -s -l 1 -r all f64_to_extF80 >> Testing f64_to_extF80 768 tests total. Errors found in f64_to_extF80: -368.800FF

Re: [RFC PATCH 08/21] contrib/gitdm: Add Mentor Graphics to the domain map

On Mon, 5 Oct 2020, Alex Bennée wrote: > Joseph Myers writes: > > > On Sun, 4 Oct 2020, Philippe Mathieu-Daudé wrote: > > > >> There is a number of contributors from this domain, > >> add its own entry to the gitdm domain map. > > > > At some p

Re: [RFC PATCH 08/21] contrib/gitdm: Add Mentor Graphics to the domain map

On Sun, 4 Oct 2020, Philippe Mathieu-Daudé wrote: > There is a number of contributors from this domain, > add its own entry to the gitdm domain map. At some point the main branding will be Siemens; not sure how you want to handle that. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 0/4] target/i386: miscellaneous x87 fixes

Ping for this patch series , and the subsequent series and individual patch . --

[PATCH v2] target/i386: reimplement fpatan using floatx80 operations

The x87 fpatan emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, as for other such instructions. Signed-off-by: Joseph Myers --- Changes in version 2: adjust

Re: [PATCH v2] target/i386: reimplement fpatan using floatx80 operations

On Tue, 23 Jun 2020, Paolo Bonzini wrote: > On 23/06/20 02:01, Joseph Myers wrote: > > The x87 fpatan emulation is currently based around conversion to > > double. This is inherently unsuitable for a good emulation of any > > floatx80 operation. Reimplement using the

[PATCH 0/2] target/i386: SSE floating-point fixes

in the second patch to cover both patches. The style checker will produce its usual inapplicable warnings about use of "volatile" in the testcase and about C99 hex float constants. Joseph Myers (2): target/i386: set SSE FTZ in correct floating-point state target/i386: fix IEEE SSE floa

[PATCH 2/2] target/i386: fix IEEE SSE floating-point exception raising

ing is done about trapping exceptions (for which there is minimal and largely broken support in QEMU's emulation in the x87 case and no support at all in the SSE case). Signed-off-by: Joseph Myers --- target/i386/cpu.h | 1 + target/i386/fpu_helper.c | 3

[PATCH 1/2] target/i386: set SSE FTZ in correct floating-point state

The code to set floating-point state when MXCSR changes calls set_flush_to_zero on >fp_status, so affecting the x87 floating-point state rather than the SSE state. Fix to call it for >sse_status instead. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 2 +- 1 file chan

Re: [PATCH] target/i386: reimplement fpatan using floatx80 operations

Testing with the glibc testsuite shows this patch needs a little more work to get correct underflow/inexact exceptions in the case where ST0 is positive and ST1/ST0 is small. I'll send a revised patch next week (I don't expect any changes in the rest of the code). -- Joseph S. Myers

Re: [PATCH] target/i386: reimplement fpatan using floatx80 operations

On Fri, 19 Jun 2020, no-re...@patchew.org wrote: > This series failed the docker-mingw@fedora build test. Please find the > testing commands and their output below. If you have Docker installed, > you can probably reproduce it locally. This is because the patch depends on my previous patch to

Re: [PATCH] target/i386: reimplement fpatan using floatx80 operations

On Fri, 19 Jun 2020, no-re...@patchew.org wrote: > This series seems to have some coding style problems. See output below for > more information: This is the same issues as before of this patch checker not understanding hex float constants, and it not seeming particularly useful to wrap lines

[PATCH] target/i386: reimplement fpatan using floatx80 operations

The x87 fpatan emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, as for other such instructions. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c

Re: [PATCH 1/5] target/i386: implement special cases for fxtract

On Tue, 23 Jun 2020, Eduardo Habkost wrote: > > +if (EXPD(temp) == 0) { > > +int shift = clz64(temp.l.lower); > > +temp.l.lower <<= shift; > > Coverity reports the following. It looks like a false positive > because floatx80_is_zero() would be true if both

[PATCH] target/i386: reimplement fyl2xp1 using floatx80 operations

for this instruction and I suspect that code was just cut-and-pasted from the trigonometric instructions (fcos, fptan, fsin, fsincos) where C2 *is* defined to be set for out-of-range arguments. Signed-off-by: Joseph Myers --- This patch *does* depend on my previous one for f2xm1, but only at the trivial

[PATCH 5/7] softfloat: return low bits of quotient from floatx80_modrem

by that point); this patch does not change that, but the m68k maintainers may wish to do so. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 23 ++- include/fpu/softfloat.h | 3 ++- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/fpu/softfloat.c b/fpu

[PATCH 4/7] softfloat: do not set denominator high bit for floatx80 remainder

. Remove the unnecessary code. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 00f362af23..423a815196 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5734,7 +5734,6 @@ floatx80 floatx80_modrem(floatx80

[PATCH 6/7] target/i386: reimplement fprem1 using floatx80 operations

The x87 fprem1 emulation is currently based around conversion to double, which is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float floatx80 remainder operations. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 96

[PATCH 1/7] softfloat: merge floatx80_mod and floatx80_rem

architectures using _rem at all are linux-user/arm/nwfpe, for FPA emulation, and openrisc, for instructions that have been removed in the latest version of the architecture), so no change is made to the code for other formats. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 49

[PATCH 0/7] softfloat, target/i386: fprem, fprem1 fixes

unchanged, which is correct (apart from normalizing pseudo-denormals) for fprem but not for fprem1 (and the old QEMU code had an incorrect optimization following the AMD manuals for fprem1). Joseph Myers (7): softfloat: merge floatx80_mod and floatx80_rem softfloat: fix floatx80 remainder ps

[PATCH 3/7] softfloat: do not return pseudo-denormal from floatx80 remainder

-by: Joseph Myers --- fpu/softfloat.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 091847beb9..00f362af23 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5691,7 +5691,7 @@ floatx80 floatx80_modrem(floatx80 a, floatx80

[PATCH 2/7] softfloat: fix floatx80 remainder pseudo-denormal check for zero

instead. Signed-off-by: Joseph Myers --- fpu/softfloat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 7b1ce7664f..091847beb9 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5726,7 +5726,7 @@ floatx80 floatx80_modrem(floatx80

[PATCH 7/7] target/i386: reimplement fprem using floatx80 operations

The x87 fprem emulation is currently based around conversion to double, which is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float floatx80 remainder operations. Signed-off-by: Joseph Myers --- target/i386/fpu_helper.c | 58

[PATCH v2 5/6] softfloat: return low bits of quotient from floatx80_modrem

by that point); this patch does not change that, but the m68k maintainers may wish to do so. Signed-off-by: Joseph Myers Reviewed-by: Richard Henderson --- fpu/softfloat.c | 23 ++- include/fpu/softfloat.h | 3 ++- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git

[PATCH v2 2/6] softfloat: fix floatx80 remainder pseudo-denormal check for zero

instead. Signed-off-by: Joseph Myers Reviewed-by: Richard Henderson --- fpu/softfloat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 7b1ce7664f..091847beb9 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5726,7 +5726,7 @@ floatx80

[PATCH v2 0/6] softfloat, target/i386: fprem, fprem1 fixes

unchanged, which is correct (apart from normalizing pseudo-denormals) for fprem but not for fprem1 (and the old QEMU code had an incorrect optimization following the AMD manuals for fprem1). Changes in version 2 of the patch series: fix comment formatting and combine patches 6 and 7. Joseph My

Re: [PATCH 6/7] target/i386: reimplement fprem1 using floatx80 operations

On Mon, 8 Jun 2020, Alex Bennée wrote: > > +uint8_t old_flags = save_exception_flags(env); > > Hmm where did this come from: This series assumes all my other recent x87 fixes (11 such patches in three series that aren't yet on master, there's also a single patch for pcmpxstrx which is

[PATCH v2 6/6] target/i386: reimplement fprem, fprem1 using floatx80 operations

The x87 fprem and fprem1 emulation is currently based around conversion to double, which is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float floatx80 remainder operations. Signed-off-by: Joseph Myers Reviewed-by: Richard Henderson

[PATCH v2 4/6] softfloat: do not set denominator high bit for floatx80 remainder

. Remove the unnecessary code. Signed-off-by: Joseph Myers Reviewed-by: Richard Henderson --- fpu/softfloat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 9d43868e4c..1552241b5e 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5736,7 +5736,6

[PATCH v2 1/6] softfloat: merge floatx80_mod and floatx80_rem

architectures using _rem at all are linux-user/arm/nwfpe, for FPA emulation, and openrisc, for instructions that have been removed in the latest version of the architecture), so no change is made to the code for other formats. Signed-off-by: Joseph Myers Reviewed-by: Richard Henderson --- fpu

[PATCH v2 3/6] softfloat: do not return pseudo-denormal from floatx80 remainder

-by: Joseph Myers Reviewed-by: Richard Henderson --- fpu/softfloat.c | 22 +++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 091847beb9..9d43868e4c 100644 --- a/fpu/softfloat.c +++ b/fpu/softfloat.c @@ -5691,7 +5691,7 @@ floatx80

[PATCH] target/i386: reimplement f2xm1 using floatx80 operations

better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Signed-off-by: Joseph Myers --- This patch depends on at least some of my previous x87 emulation fixes being present (probably only the ones in the recent pull request; I don't think

[PATCH v2] target/i386: correct fix for pcmpxstrx substring search

yte operand (that is, the case that would be broken by a simple revert of the non-empty-string part of my 2017 patch). Signed-off-by: Joseph Myers --- Version 2: remove stray string constant from test that caused compiler warning; adjust target for which QEMU_OPTS is set, which will hopefully cause i