diff options
| author | beetrees <b@beetr.ee> | 2025-03-10 02:44:27 +0000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-03-10 09:44:27 +0700 |
| commit | 8b9c91ec7da0ca3daab8ff6711126443e500bb66 (patch) | |
| tree | 2fd76fd6a9e9ea442b149058960ce4685d1d35c1 /clang/lib/CodeGen/CodeGenFunction.cpp | |
| parent | 82f2b661101d1133b72872141009035f01a42595 (diff) | |
| download | llvm-8b9c91ec7da0ca3daab8ff6711126443e500bb66.zip llvm-8b9c91ec7da0ca3daab8ff6711126443e500bb66.tar.gz llvm-8b9c91ec7da0ca3daab8ff6711126443e500bb66.tar.bz2 | |
[APFloat] Fix `IEEEFloat::addOrSubtractSignificand` and `IEEEFloat::normalize` (#98721)
Fixes #63895
Fixes #104984
Before this PR, `addOrSubtractSignificand` presumed that the loss came
from the side being subtracted, and didn't handle the case where lhs ==
rhs and there was loss. This can occur during FMA. This PR fixes the
situation by correctly determining where the loss came from and handling
it appropriately.
Additionally, `normalize` failed to adjust the exponent when the
significand is zero but `lost_fraction != lfExactlyZero`. This meant
that the test case from #63895 was rounded incorrectly as the loss
wasn't adjusted to account for the exponent being below the minimum
exponent. This PR fixes this by only skipping the exponent adjustment if
the significand is zero and there was no lost fraction.
(Note to reviewer: I don't have commit access)
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions