| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Unnormal values are a feature of some very old x87 processors. We handle
them correctly for the most part -- the only exception was an unnormal
value whose significand happened to be zero. In this case the APFloat
was still initialized as normal number (category = fcNormal), but a
subsequent toString operation would assert because the math would
produce nonsensical values for the zero significand.
During review, it was decided that the correct way to fix this is to
treat all unnormal values as NaNs (as that is what any >=386 processor
will do).
The issue was discovered because LLDB would crash when trying to print
some "long double" values.
Reviewers: skatkov, scanon, gottesmm
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41868
llvm-svn: 331884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method IEEEFloat::convertFromStringSpecials() does not recognize
the "+Inf" and "-Inf" strings but these strings are printed for
the double Infinities by the IEEEFloat::toString().
This patch adds the "+Inf" and "-Inf" strings to the list of recognized
patterns in IEEEFloat::convertFromStringSpecials().
Re-landing after fix.
Reviewers: sberg, bogner, majnemer, timshen, rnk, skatkov, gottesmm, bkramer, scanon, anna
Reviewed By: anna
Subscribers: mkazantsev, FlameTop, llvm-commits, reames, apilipenko
Differential Revision: https://reviews.llvm.org/D38030
llvm-svn: 321054
|
|
|
|
|
|
|
|
|
|
|
|
| |
fmod specification requires the sign of the remainder is
the same as numerator in case remainder is zero.
Reviewers: gottesmm, scanon, arsenm, davide, craig.topper
Reviewed By: scanon
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D39225
llvm-svn: 317081
|
|
|
|
| |
llvm-svn: 316158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method IEEEFloat::convertFromStringSpecials() does not recognize
the "+Inf" and "-Inf" strings but these strings are printed for
the double Infinities by the IEEEFloat::toString().
This patch adds the "+Inf" and "-Inf" strings to the list of recognized
patterns in IEEEFloat::convertFromStringSpecials().
Reviewers: sberg, bogner, majnemer, timshen, rnk, skatkov, gottesmm, bkramer, scanon
Reviewed By: skatkov
Subscribers: apilipenko, reames, llvm-commits
Differential Revision: https://reviews.llvm.org/D38030
llvm-svn: 316156
|
|
|
|
| |
llvm-svn: 316079
|
|
|
|
| |
llvm-svn: 311875
|
|
|
|
|
|
|
|
| |
Previously, we would just assert instead.
Differential Revision: https://reviews.llvm.org/D36961
llvm-svn: 311351
|
|
|
|
|
|
| |
This test pretty clearly should be calling 'maxnum' here. =]
llvm-svn: 307519
|
|
|
|
|
|
|
|
|
|
| |
by a valid octal digit.
The length argument shows that this was in fact the intent.
This was pointed out in IRC, thanks to eddyb!
llvm-svn: 307496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
snprinf
This should fix the bug https://bugs.llvm.org/show_bug.cgi?id=12906
To print the FP constant AsmWriter does the following:
1) convert FP value to String (actually using snprintf function which is locale dependent).
2) Convert String back to FP Value
3) Compare original and got FP values. If they are not equal just dump as hex.
The problem happens on the 2nd step when APFloat does not expect group delimiter or
fraction delimiter other than period symbol and so on, which can be produced on the
first step if LLVM library is used in an environment with corresponding locale set.
To fix this issue the locale independent APFloat:toString function is used.
However it prints FP values slightly differently than snprintf does. Specifically
it suppress trailing zeros in significant, use capital E and so on.
It results in 117 test failures during make check.
To avoid this I've also updated APFloat.toString a bit to pass make check at least.
Reviewers: sberg, bogner, majnemer, sanjoy, timshen, rnk
Reviewed By: timshen, rnk
Subscribers: rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D32276
llvm-svn: 300943
|
|
|
|
| |
llvm-svn: 299257
|
|
|
|
|
|
|
|
| |
The previous version was prone to intermediate rounding or overflow.
Differential Revision: https://reviews.llvm.org/D29346
llvm-svn: 299256
|
|
|
|
| |
llvm-svn: 293019
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: echristo, hfinkel, kbarton, iteratee
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28382
llvm-svn: 292860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(IEEEdouble, IEEEdouble)
Summary:
This patch changes the layout of DoubleAPFloat, and adjust all
operations to do either:
1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl,
then run the old algorithm.
2) Do the right thing directly.
1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral,
convertFromString, next, convertToInteger, convertFromAPInt,
convertFromSignExtendedInteger, convertFromZeroExtendedInteger,
convertToHexString, toString, getExactInverse.
2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized,
compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest,
isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile.
I could split this into two patches, e.g. use
1) for all operatoins first, then incrementally change some of them to
2). I didn't do that, because 1) involves code that converts data between
PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may
pessimize the compiler. Instead, I find easy functions and use
approach 2) for them directly.
Next step is to implement move multiply and divide from 1) to 2). I don't
have plans for other functions in 1).
Differential Revision: https://reviews.llvm.org/D27872
llvm-svn: 292839
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27833
llvm-svn: 291189
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: iteratee
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27828
llvm-svn: 289904
|
|
|
|
| |
llvm-svn: 289649
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26817
llvm-svn: 289474
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I looked at libgcc's implementation (which is based on the paper,
Software for Doubled-Precision Floating-Point Computations", by Seppo Linnainmaa,
ACM TOMS vol 7 no 3, September 1981, pages 272-283.) and made it generic to
arbitrary IEEE floats.
Differential Revision: https://reviews.llvm.org/D26817
llvm-svn: 289472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes PR30869.
In D25977 I meant to change all functions that care about lifetime. I
changed constructors, factory functions, but I missed member/free
functions that return new instances. This patch changes them.
Reviewers: hfinkel, kbarton, echristo, joerg
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D26269
llvm-svn: 286060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed some unused headers, replaced some headers with forward class declarations.
Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'
Patch by Eugene Kosov <claprix@yandex.ru>
Differential Revision: http://reviews.llvm.org/D19219
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
|
|
|
|
| |
llvm-svn: 264219
|
|
|
|
| |
llvm-svn: 263950
|
|
|
|
| |
llvm-svn: 263370
|
|
|
|
|
|
|
| |
This was incorrect for denormals, and also failed
on longer exponent ranges.
llvm-svn: 263369
|
|
|
|
|
|
|
|
| |
Useful utility function; this wasn't too hard to do before, but also wasn't
obviously discoverable. Make it explicit. Reviewed offline by Michael
Gottesman.
llvm-svn: 253254
|
|
|
|
|
|
| |
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
|