diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2024-02-10 12:51:39 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2024-02-10 12:51:39 +0100 |
| commit | 1e87fcf200897b64ca428c8ef80c3ad876828caf (patch) | |
| tree | d5a45bf87de37f867b542ebdd01ee8bc3242b819 /gcc/tree-vect-loop.cc | |
| parent | b2684e5512b097fbaa63dd18c35f8af4b351920c (diff) | |
| download | gcc-1e87fcf200897b64ca428c8ef80c3ad876828caf.zip gcc-1e87fcf200897b64ca428c8ef80c3ad876828caf.tar.gz gcc-1e87fcf200897b64ca428c8ef80c3ad876828caf.tar.bz2 | |
libgcc: Fix a bug in _BitInt -> dfp conversions
The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of the remainder were non-zero.
Now, in the dfp/bitint-4.c test in one case the remainder happens
to have least significant 64 bits zero and then the higher limbs are
non-zero; with 32-bit limbs that means 2 least significant limbs are zero
and so the code acted as if it was exactly divisible.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
limbs into inexact rather than just first two.
* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
Diffstat (limited to 'gcc/tree-vect-loop.cc')
0 files changed, 0 insertions, 0 deletions