The standards aren't clear about how IEEE-754 subnormal values interact
with the intrinsic function SPACING. Four compilers interpret the
standard such that SPACING(x) will return a value never less than
TINY(x); one compiler returns TINY(x) for ABS(x) <= TINY(x) but can
return SPACING(x) < TINY(x) for some ABS(x) > TINY(x); one other
compiler works similarly, but also oddly returns SPACING(x) < TINY(x)
for ABS(x) >= TINY(x)/2.
Follow the most common precedent.
The generation of 80-bit x87 floating-point infinities was incorrect in
Normalize(), the comparison for IEEE_NEXT_AFTER needs to use the most
precise type of its arguments, and we don't need to warn about overflows
from +/-HUGE() to infinity. Warnings about NaN arguments remain in
place, and enabled by default, as their usage may or may not be
portable, and their appearance in a real code seems most likely to
signify an earlier error.
IEEE_ARITHMETIC intrinsic module procedures IEEE_NEXT_AFTER,
IEEE_NEXT_DOWN, and IEEE_NEXT_UP, and intrinsic NEAREST return larger or
smaller values adjacent to their primary REAL argument. The four
procedures vary in how the direction is chosen, in how special cases are
treated, and in what exceptions are generated. Implement the three
IEEE_ARITHMETIC procedures. Update the NEAREST implementation to support
all six REAL kinds 2,3,4,8,10,16, and fix several bugs.
IEEE_NEXT_AFTER(X,Y) returns a NaN when Y is a NaN as that seems to be
the universal choice of other compilers.
Change the front end compile time implementation of these procedures to
return normal (HUGE) values for infinities when applicable, rather than
always returning the input infinity.
The intrinsic function OUT_OF_RANGE() lacks support in lowering and the
runtime. This patch obviates a need for any such support by implementing
OUT_OF_RANGE() via rewriting in semantics. This rewriting of
OUT_OF_RANGE() calls replaces the existing code that folds
OUT_OF_RANGE() calls with constant arguments.
Some changes and fixes were necessary outside of OUT_OF_RANGE()'s
folding code (now rewriting code), whose testing exposed some other
issues worth fixing.
- The common::RealDetails<> template class was recoded in terms of a new
base class with a constexpr constructor, so that the the characteristics
of the various REAL kinds could be queried dynamically as well. This
affected some client usage.
- There were bugs in the code that folds TRANSFER() when the type of X
or MOLD was REAL(10) -- this is a type that occupies 16 bytes per
element in execution memory but only 10 bytes (was 12) in the data of
std::vector<Scalar<>> in a Constant<>.
- Folds of REAL->REAL conversions weren't preserving infinities.
The Fortran standard defines real MOD and MODULO with expressions like
MOD(a,p) = a - AINT(a/p)*p. Unfortunately, these definitions have poor
accuracy when a is much larger in magnitude than p, and every Fortran
compiler uses better algorithms instead.
Fixes llvm-test-suite/Fortran/gfortran/regression/mod_large_1.f90.
The code to fold NEAREST would return a value that's too large when
transitioning from a normal number to a subnormal.
Fixes llvm-test-suite/Fortran/gfortran/regression/nearest_1.f90.
SPACING() must return TINY() for zero arguments (which we do)
and also for subnormal values smaller than TINY() in absolute value,
which we get wrong. Fix folding and the runtime.
Differential Revision: https://reviews.llvm.org/D151272
The implementation of the folding code for SET_EXPONENT() was written
in such a fashion as to convert the I= actual argument value to a 32-bit
integer. Which is usually not a problem, but it's not always correct
and a test case ran into trouble with it. Fix to allow any kind of
INTEGER without conversion.
Differential Revision: https://reviews.llvm.org/D135203
The intrinsic function SPACING() was being folded to the smallest
normal number (TINY(x)) rather than to a smaller subnormal result
when that result really was subnormal.
Differential Revision: https://reviews.llvm.org/D132155
The implementations of folding for the intrinsic functions SCALE and SET_EXPONENT
do not cope correctly with numbers in the subnormal range. Fix SCALE,
then modify SET_EXPONENT to be a special case of SCALE.
Differential Revision: https://reviews.llvm.org/D131099
In folding and in the runtime library for real MOD/MODULO(A,P),
detect overflow from the division A/P and return a properly signed
zero result. (When A/P overflows and both A and P are finite numbers
with nonzero P, the quotient would be a large integer when rounded to
the precision of the floating-point representation.)
Differential Revision: https://reviews.llvm.org/D129020
Replace the latter half of the SQRT() folding algorithm with code that
calculates an exact root with extra rounding bits, and then lets the
usual normalization and rounding code do the right thing. Extend
tests to catch regressions.
Differential Revision: https://reviews.llvm.org/D128395
Evaluate real-valued references to the intrinsic functions MODULO
and MOD at compilation time without recourse to an external math
library.
Differential Revision: https://reviews.llvm.org/D125151
Fold references to the intrinsic function DIM with constant real
arguments. And clean up folding of comparisons with NaNs to address
a problem noticed in testing -- NaNs should successfully compare
unequal to all values, including themselves, instead of failing all
comparisons.
Differential Revision: https://reviews.llvm.org/D125146
The related real number system inquiry functions SPACING()
and RRSPACING() can be folded for constant arguments.
See 16.9.164 & 16.9.180 in Fortran 2018.
Differential Revision: https://reviews.llvm.org/D125100
The float number is represented as (-1)^s * 1.f * 2^(-127) for 32-bit,
where s is the signed flag, f is the mantissa. When the exponent bits
are all zeros, the float number is represented as (-1)^s * 0.f *2^(-126)
for 32-bit, in which case, the intPart is '0'.
Reviewed By: Jean Perier
https://reviews.llvm.org/D123673
During real range reduction to [0.5, 4) with
SQRT(2**(2a) * x) = SQRT(2**(2a)) * SQRT(x) = 2**a * SQRT(x)
we fall into inf. recursion if IsZero() == true.
Explicitly handle SQRT(0.0) instead of additional checks during folding. Also
add helpers for +0.0/-0.0 generation to clean up a bit.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D123131
Implement constant folding for the intrinsic function NEAREST()
and the related functions IEEE_NEXT_AFTER(), IEEE_NEXT_UP(), and
IEEE_NEXT_DOWN().
Differential Revision: https://reviews.llvm.org/D122510
The algorithm used to fold SQRT has some holes that
led to test failures; debug and add more tests.
Differential Revision: https://reviews.llvm.org/D110744
Implement IEEE Real::SQRT() operation, then use it to
also implement Real::HYPOT(), which can then be used directly
to implement Complex::ABS().
Differential Revision: https://reviews.llvm.org/D109250
Flang front end function DumpHexadecimal generates a string
representation of a REAL value. When the value is a NaN, the string
contains a blank, as in "NaN 0x7fc00000". This function is used by
lowering to generate a string that is then passed to llvm Support
function convertFromStringSpecials, which does not expect a blank
in the string. Remove the blank to allow correct recognition of a
NaN by this llvm function.
Note that function DumpHexadecimal is not exercised by the front end
itself. This functionality is only exercised by code that is not yet
present in llvm.
The call to the binary->decimal formatter in real.cpp was cheating
by using a reinterpret_cast<> to extract its binary value.
Use a more principled and portable approach by extending the
API of evaluate::Integer<> to include ToUInt<>()/ToSInt<>()
member function templates that do the "right" thing. Retain
ToUInt64()/ToSInt64() for compatibility.
Differential revision: https://reviews.llvm.org/D89435
This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]
As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()
It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries
*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.
[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Running clang-format-7
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Removing residue of ostream library
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@a3507d44b8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
