| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Tested with md5 sum of object code
Reported by: swildner@DragonFlyBSD.org
Submitted by: bde
|
| |
|
|
|
|
|
|
|
|
| |
are workarounds for various symptoms of the problem described in clang
bugs 3929, 8100, 8241, 10409, and 12958.
The regression tests did their job: they failed, someone brought it
up on the mailing lists, and then the issue got ignored for 6 months.
Oops. There may still be some regressions for functions we don't have
test coverage for yet.
|
| |
|
|
|
| |
exactly cancels with z, return the low part of x*y instead of
discarding it.
|
| |
|
|
|
|
|
|
|
|
| |
round-to-nearest mode when the result, rounded to twice machine
precision, was exactly halfway between two machine-precision
values. The essence of the fix is to simulate a "sticky bit" in
the pathological cases, which is how hardware implementations
break the ties.
MFC after: 1 month
|
| |
|
|
|
| |
extra-precision add and multiply operations. This simplifies future
work but shouldn't result in any functional change.
|
| |
|
|
|
|
|
|
|
| |
- fma(x, y, z) returns z, not NaN, if z is infinite, x and y are finite,
x*y overflows, and x*y and z have opposite signs.
- fma(x, y, z) doesn't generate an overflow, underflow, or inexact exception
if z is NaN or infinite, as per IEEE 754R.
- If the rounding mode is set to FE_DOWNWARD, fma(1.0, 0.0, -0.0) is -0.0,
not +0.0.
|
| |
|
|
| |
remove the XXX comments, which no longer apply.
|
| |
|
