| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
All supported platforms have half-way decent C99 support.
llvm-svn: 231679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.
Unit tests for this case and related signed zero FMA results are included.
Fixes <rdar://problem/18925551>.
llvm-svn: 225123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.
fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)
This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.
llvm-svn: 222374
|
|
|
|
|
|
| |
by value having cleared the sign bit.
llvm-svn: 219485
|
|
|
|
| |
llvm-svn: 219475
|
|
|
|
|
|
|
|
| |
to what we actually want ilogb implementation. This makes everything
*much* easier to deal with and is actually what we want when using it
anyways.
llvm-svn: 219474
|
|
|
|
| |
llvm-svn: 219473
|
|
|
|
|
|
| |
to implement complex division in the constant folder of Clang.
llvm-svn: 219471
|
|
|
|
|
|
|
|
|
|
|
|
| |
code using it more readable.
Also add a copySign static function that works more like the standard
function by accepting the value and sign-carying value as arguments.
No interesting logic here, but tests added to cover the basic API
additions and make sure they do something plausible.
llvm-svn: 219453
|
|
|
|
| |
llvm-svn: 210442
|
|
|
|
|
|
| |
Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.
llvm-svn: 210428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-commit of r189442; I'll follow up with clang changes.
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
llvm-svn: 189624
|
|
|
|
|
|
| |
This is breaking numerous Clang tests on the buildbot.
llvm-svn: 189447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
llvm-svn: 189442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the
interpretation of the sign of NaNs. In order to remove an irrelevant
variable that most floating point implementations do not use,
standardize add, sub, mul, div, mod so that operating anything with
NaN always yields a positive NaN.
In a later commit I am going to update the APIs for creating NaNs so
that one can not even create a negative NaN.
llvm-svn: 187314
|
|
|
|
|
|
|
|
|
|
|
| |
There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to assertion failures and incorrect rounding for overlong
hex float literals.
Fixes PR16643.
llvm-svn: 186539
|
|
|
|
|
|
|
|
| |
terminators.
rdar://14323230
llvm-svn: 185397
|
|
|
|
|
|
| |
result categories, and result statuses.
llvm-svn: 185050
|
|
|
|
| |
llvm-svn: 185045
|
|
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185044
|
|
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185043
|
|
|
|
| |
llvm-svn: 184974
|
|
|
|
| |
llvm-svn: 184715
|
|
|
|
|
|
| |
values are computed correctly.
llvm-svn: 184714
|
|
|
|
|
|
|
|
| |
The old isNormal is already functionally replaced by the method isFiniteNonZero
in r184350 and all references to said method were replaced in LLVM/clang in
r184356/134366.
llvm-svn: 184449
|
|
|
|
| |
llvm-svn: 184447
|
|
|
|
|
|
|
|
| |
tests in unittests.
I forgot to to do this in r184356. The only references were in APFloatTest.cpp.
llvm-svn: 184366
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:
1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.
llvm-svn: 184350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically the following work was done:
1. If the operation was not implemented, I implemented it.
2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.
Also unittests have been added for all of the functions which did not
already have a unittest.
llvm-svn: 183179
|
|
|
|
| |
llvm-svn: 183081
|
|
|
|
| |
llvm-svn: 183028
|
|
|
|
|
|
|
|
| |
function APFloat::next(bool nextDown).
rdar://13852078
llvm-svn: 182945
|
|
|
|
| |
llvm-svn: 182897
|
|
|
|
|
|
|
|
|
| |
consider the result to be denormal.
I additionally changed certain checks to use EXPECT_FALSE instead of a boolean
complement with EXPECT_TRUE.
llvm-svn: 182896
|
|
|
|
| |
llvm-svn: 182894
|
|
|
|
|
|
| |
-14.5f + 225.0f" to 225.0f.
llvm-svn: 181715
|
|
|
|
|
|
|
|
| |
smaller type.
Fixes PR15054.
llvm-svn: 173459
|
|
|
|
| |
llvm-svn: 171764
|
|
|
|
| |
llvm-svn: 169250
|
|
|
|
|
|
|
|
| |
fmul transform.
This is safe for x87 long doubles and ppc double doubles too.
llvm-svn: 167582
|
|
|
|
|
|
|
|
|
|
|
|
| |
treating it as if it were an IEEE floating-point type with 106-bit
mantissa.
This makes compile-time arithmetic on "long double" for PowerPC
in clang (in particular parsing of floating point constants)
work, and fixes all "long double" related failures in the test
suite.
llvm-svn: 166951
|
|
|
|
|
|
|
|
| |
date, don't rely on it.
Add a couple of unit tests for special floats. Fixes 13929, found by MemorySanitizer.
llvm-svn: 164698
|
|
|
|
|
|
| |
infinity. Problem and solution identified by Steve Canon.
llvm-svn: 161969
|
|
|
|
|
|
| |
results for negative inputs to trunc. Add unit tests to verify this behavior.
llvm-svn: 161929
|
|
|
|
|
|
|
|
| |
was returning incorrect values in rare cases, and incorrectly marking
exact conversions as inexact in some more common cases. Fixes PR11406, and a
missed optimization in test/CodeGen/X86/fp-stack-O0.ll.
llvm-svn: 145141
|
|
|
|
| |
llvm-svn: 141831
|
|
|
|
|
|
| |
Found by accident while reviewing a patch to nearby code.
llvm-svn: 141816
|
|
|
|
|
|
|
|
| |
The APFloat "Zero" test was actually calling the
APFloat(const fltSemantics &, integerPart) constructor, and EXPECT_EQ was
treating 0 and -0 as equal.
llvm-svn: 138745
|
|
|
|
|
|
| |
memory for the result.
llvm-svn: 135259
|
|
|
|
|
|
|
|
|
| |
denormal multiplication.
Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.
llvm-svn: 128555
|