| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
This is breaking numerous Clang tests on the buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
terminators.
rdar://14323230
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185397 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
result categories, and result statuses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
result categories, and result status.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
result categories, and result status.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
values are computed correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184714 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
tests in unittests.
I forgot to to do this in r184356. The only references were in APFloatTest.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183179 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
function APFloat::next(bool nextDown).
rdar://13852078
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182897 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
consider the result to be denormal.
I additionally changed certain checks to use EXPECT_FALSE instead of a boolean
complement with EXPECT_TRUE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
-14.5f + 225.0f" to 225.0f.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
smaller type.
Fixes PR15054.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169250 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
fmul transform.
This is safe for x87 long doubles and ppc double doubles too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
date, don't rely on it.
Add a couple of unit tests for special floats. Fixes 13929, found by MemorySanitizer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164698 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
infinity. Problem and solution identified by Steve Canon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161969 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
results for negative inputs to trunc. Add unit tests to verify this behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161929 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141831 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Found by accident while reviewing a patch to nearby code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
The APFloat "Zero" test was actually calling the
APFloat(const fltSemantics &, integerPart) constructor, and EXPECT_EQ was
treating 0 and -0 as equal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138745 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
memory for the result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
denormal multiplication.
Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128555 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98701 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
payloads. APFloat's internal folding routines always make QNaNs now,
instead of sometimes making QNaNs and sometimes SNaNs depending on the
type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97278 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
as undefined. Fixes an assertion in APFloat::toString noticed by Dale.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95196 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
major bugs in long-precision conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
smallest-normalized-magnitude values in a given FP semantics.
Provide an APFloat-to-string conversion which I am quite ready to admit could
be much more efficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92126 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
and many new unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79574 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79540 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79218 91177308-0d34-0410-b5e6-96231b3b80d8
|