aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ADT/APFloatTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2015-01-04[APFloat][ADT] Fix sign handling logic for FMA results that truncate to zero.Lang Hames1-0/+41
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
2014-11-19[ADT] Fix PR20728 - Incorrect APFloat::fusedMultiplyAdd results for x86_fp80.Lang Hames1-0/+12
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
2014-10-10[ADT] Add an (ADL-friendly) abs free function for APFloat that returnsChandler Carruth1-0/+38
by value having cleared the sign bit. llvm-svn: 219485
2014-10-10Add minnum / maxnum to APFloatMatt Arsenault1-0/+22
llvm-svn: 219475
2014-10-10[ADT] Replace the logb implementation with the simpler and much closerChandler Carruth1-49/+27
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
2014-10-10[ADT] Add the scalbn function for APFloat.Chandler Carruth1-0/+43
llvm-svn: 219473
2014-10-10[ADT] Implement the 'logb' functionality for APFloat. This is necessaryChandler Carruth1-0/+51
to implement complex division in the constant folder of Clang. llvm-svn: 219471
2014-10-09[ADT] Add basic operator overloads for arithmetic to APFloat to makeChandler Carruth1-0/+20
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
2014-06-08[C++11] Use 'nullptr'.Craig Topper1-3/+3
llvm-svn: 210442
2014-06-08APFloat: x - NaN needs to flip the signbit of NaN when x is a number.Stephen Canon1-24/+24
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
2013-08-29Change default # of digits for APFloat::toStringEli Friedman1-4/+5
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
2013-08-28Revert r189442 "Change default # of digits for APFloat::toString"Ted Kremenek1-5/+4
This is breaking numerous Clang tests on the buildbot. llvm-svn: 189447
2013-08-28Change default # of digits for APFloat::toStringEli Friedman1-4/+5
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
2013-07-27[APFloat] Make all arithmetic operations with NaN produce positive NaNs.Michael Gottesman1-86/+36
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
2013-07-17Handle '.' correctly in hex float literal parsing.Eli Friedman1-1/+6
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
2013-07-01[APFloat] Ensure that we can properly parse strings that do not have null ↵Michael Gottesman1-0/+25
terminators. rdar://14323230 llvm-svn: 185397
2013-06-27[APFloat] Added unittest for APFloat.divide that checks special cases, ↵Michael Gottesman1-0/+304
result categories, and result statuses. llvm-svn: 185050
2013-06-27Removed two logging printf statements from the APFloat tests... = /.Michael Gottesman1-8/+0
llvm-svn: 185045
2013-06-26[APFloat] Added unittest for APFloat.multiply that checks special cases, ↵Michael Gottesman1-0/+307
result categories, and result status. llvm-svn: 185044
2013-06-26[APFloat] Added unittest for APFloat.subtract that checks special cases, ↵Michael Gottesman1-0/+303
result categories, and result status. llvm-svn: 185043
2013-06-26[APFloat] Removed debugging cruft that snuck in.Michael Gottesman1-4/+0
llvm-svn: 184974
2013-06-24[APFloat] Removed trailing whitespace from unittests.Michael Gottesman1-14/+14
llvm-svn: 184715
2013-06-24[APFloat] Added a large unittest for APFloat.add that checks that special ↵Michael Gottesman1-0/+302
values are computed correctly. llvm-svn: 184714
2013-06-20[APFloat] Rename isIEEENormal => isNormal and remove old isNormal method.Michael Gottesman1-7/+7
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
2013-06-20[APFloat] Fix typo in test so we actually test if we handle denormals.Michael Gottesman1-4/+4
llvm-svn: 184447
2013-06-19[APFloat] Changed APFloat::isNormal => APFloat::isFiniteNonZero for all ↵Michael Gottesman1-8/+8
tests in unittests. I forgot to to do this in r184356. The only references were in APFloatTest.cpp. llvm-svn: 184366
2013-06-19[APFloat] Added isFiniteNonZero predicate.Michael Gottesman1-0/+28
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
2013-06-04IEEE-754R 5.7.2 General Operations is* operations (except for isCanonical).Michael Gottesman1-0/+61
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
2013-06-01Try to avoid "integer literal too big" warnings from older GCCs.Benjamin Kramer1-7/+7
llvm-svn: 183081
2013-05-31[APFloat] Added a unittest for APFloat::getZero.Michael Gottesman1-0/+37
llvm-svn: 183028
2013-05-30Implement IEEE-754R 2008 nextUp/nextDown functions in the guise of the ↵Michael Gottesman1-0/+420
function APFloat::next(bool nextDown). rdar://13852078 llvm-svn: 182945
2013-05-30Added a unittest for APFloat::getSmallestNormalized.Michael Gottesman1-0/+30
llvm-svn: 182897
2013-05-30Added code to the unittest for APFloat::getSmallest to double check that we ↵Michael Gottesman1-2/+6
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
2013-05-29Add a unittest for APFloat::getSmallest.Michael Gottesman1-0/+26
llvm-svn: 182894
2013-05-13Fix a bug that APFloat::fusedMultiplyAdd() mistakenly evaluate "14.5f * ↵Shuxin Yang1-0/+23
-14.5f + 225.0f" to 225.0f. llvm-svn: 181715
2013-01-25APFloat: Make sure that we get a well-formed x87 NaN when converting from a ↵Benjamin Kramer1-0/+26
smaller type. Fixes PR15054. llvm-svn: 173459
2013-01-07Implement APFloat::isDenormal()Shuxin Yang1-0/+52
llvm-svn: 171764
2012-12-04Sort the #include lines for unittest/...Chandler Carruth1-4/+4
llvm-svn: 169250
2012-11-08Drop the limitation to IEEE floating point types from the fdiv of pow2 -> ↵Benjamin Kramer1-0/+6
fmul transform. This is safe for x87 long doubles and ppc double doubles too. llvm-svn: 167582
2012-10-29Implement arithmetic on APFloat with PPCDoubleDouble semantics byUlrich Weigand1-0/+36
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
2012-09-26APFloat::roundToIntegral: Special values don't keep the exponent value up to ↵Benjamin Kramer1-0/+17
date, don't rely on it. Add a couple of unit tests for special floats. Fixes 13929, found by MemorySanitizer. llvm-svn: 164698
2012-08-15Fix another roundToIntegral bug where very large values could become ↵Owen Anderson1-1/+14
infinity. Problem and solution identified by Steve Canon. llvm-svn: 161969
2012-08-15Fix a problem with APFloat::roundToIntegral where it would return incorrect ↵Owen Anderson1-0/+30
results for negative inputs to trunc. Add unit tests to verify this behavior. llvm-svn: 161929
2011-11-26Fix APFloat::convert so that it handles narrowing conversions correctly; itEli Friedman1-0/+24
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
2011-10-12Attempt to fix MSVC build.Eli Friedman1-2/+2
llvm-svn: 141831
2011-10-12Fix APFloat::getLargest so that it actually returns the correct value. ↵Eli Friedman1-0/+5
Found by accident while reviewing a patch to nearby code. llvm-svn: 141816
2011-08-29Fix a test that wasn't testing the right thing.Matt Beaumont-Gay1-4/+6
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
2011-07-15Add an APFloat::convertToInt(APSInt) function that automatically manages theJeffrey Yasskin1-0/+49
memory for the result. llvm-svn: 135259
2011-03-30Avoid turning a floating point division with a constant power of two into a ↵Benjamin Kramer1-4/+2
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
2011-03-30Add APFloat::getExactInverse.Benjamin Kramer1-0/+23
The idea is, that if an ieee 754 float is divided by a power of two, we can turn the division into a cheaper multiplication. This function sees if we can get an exact multiplicative inverse for a divisor and returns it if possible. This is the hard part of PR9587. I tested many inputs against llvm-gcc's frotend implementation of this optimization and didn't find any difference. However, floating point is the land of weird edge cases, so any review would be appreciated. llvm-svn: 128545
generated by cgit v1.1 at 2025-10-16 15:58:28 +0000