For `LDBL_MANT_DIG == 113` targets the FortranFloat128Math library
is just an interface library that provides sources and compilation
options to be used for building FortranRuntime - there are not extra
dependencies on other libraries, so it can be a part of FortranRuntime,
which helps to avoid extra linking steps in the compiler driver.
Targets with __float128 support in libc will also use this path.
Other targets, where the math support comes from
FLANG_RUNTIME_F128_MATH_LIB,
FortranFloat128Math is built as a standalone static library,
and the compiler driver needs to conduct the linking.
Flang APIs for COMPLEX(16) are just thin C wrappers around
the C math functions. Flang uses C _Complex ABI for passing/returning
COMPLEX values, so the runtime is aligned to this.
For `LDBL_MANT_DIG == 113` targets the REAL(16) versions of F18
runtime APIs can stay and should better stay in FortranRuntime.
This way, no additional linking actions are required, because
glibc provides all that is needed.
I thought I would isolate all REAL(16) implementations (both
via `__float128` and `long double`) into Float128Math library,
but that was a bad idea.
This should fix aarch64 buildbots failing gfortran tests.
When testing the arguments to see whether they are integers, check first
that they are within the maximum range of a 64-bit integer; otherwise, a
value of larger magnitude will set an invalid operand exception flag.
When a real-valued reference to the MOD/MODULO intrinsic functions has
operands that are exact integers, use the fast exact integer algorithm
rather than calling std::fmod.
The new accurate algorithm for real MOD and MODULO in the runtime is not
as fast as std::fmod(), which is also accurate. So use std::fmod() for
those floating-point types that it supports.
Fixes https://github.com/llvm/llvm-project/issues/78641.
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.
When the result of NEAREST() has an exponent less than that of the
argument (e.g., NEAREST(1.,-1.) and NEAREST(-1.,1.)), the result was
wrong, because the increment value uses the result of SPACING() in terms
of the argument. Fix by just calling into the C runtime routine
std::nextafter().
This patch enables more numeric (mod, sum, matmul, etc.) APIs,
and some others.
I added new macros to disable warnings about using C++ STD methods
like operators of std::complex, which do not have __device__ attribute.
This may probably result in unresolved references, if the header files
implementation relies on libstdc++. I will need to follow up on this.
This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.
Experimental: do not merge yet.
Differential Revision: https://reviews.llvm.org/D154660
This update allows constant folding for many 128 bit floating point intrinsics
through the library quadmath, which is only available on some platforms.
Differential Revision: https://reviews.llvm.org/D156435
The f18 clause 16.9.80 description of the FRACTION(X) intrinsic states:
Result Value. The result has the value ....
If X has the value zero, the result is zero.
If X is an IEEE NaN, the result is that NaN.
If X is an IEEE infinity, the result is an IEEE NaN.
This clause does not specify whether fraction(-0.0) should be -0.0 or +0.0.
However, a folded result and a runtime result should be consistent, and
returning -0.0 is more in line with the result for fraction(NaN).
For this test:
print '(2f6.1)', 0.0, fraction(0.0)
call f(0.0)
print '(2f6.1)', -0.0, fraction(-0.0)
call f(-0.0)
end
subroutine f(x)
print '(2f6.1)', x, fraction(x)
end
Current output is:
0.0 0.0
0.0 0.0
-0.0 -0.0
-0.0 0.0
Change that to:
0.0 0.0
0.0 0.0
-0.0 -0.0
-0.0 -0.0
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
Exponentiation is lowered to either math::FPowI or Fortran runtime
call (in case of --math-runtime=precise).
MathToFuncs convertor will convert math::FPowI operations with
exponent width >32 to calls of outlined implementations and otherwise
will leave the operation to MathToLLVM convertor.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139806
As Fortran 2018 16.9.169, the argument of selected_int_kind is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering and runtime for variables in this intrinsic.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D129959
As Fortran 2018 16.9.170, the argument of `selected_real_kind` is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering this intrinsic for variables using runtime.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D130183
For aint/anint, LLVM conversion operations llvm.trunc and llvm.round
can support the edge case of aint(-0.) and anint(-0.). The output is -0.
and it is the same of `gfortran` and `classic flang`, while the output
of `ifort` is 0.. The `real(10)/real(16)` is not supported before.
Support it and remove the runtime functions for aint/anint.
For nint, `gfortran`, `ifort`, and LLVM Flang using llvm.lround have
different results when the magnitude of argument is more than the max of
result value range. So delay its support in lowering after more
investigations.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D130024
Section 16.9.171 says:
If X has the value zero, the result has the same value as X
So if X is -0.0, SET_EXPONENT should return -0.0.
Differential Revision: https://reviews.llvm.org/D129309
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
On targets with __float128 available and distinct from long double,
use it to support more kind=16 entry points. This affects mostly
x86-64 targets. This means that more runtime entry points are
defined for lowering to call.
Delete Common/long-double.h and its LONG_DOUBLE macro in favor of
testing the standard macro LDBL_MANT_DIG.
Differential Revision: https://reviews.llvm.org/D127025
Add extra arguments and checks to the runtime support library so that
a call to the intrinsic functions MOD and MODULO with "denominator"
argument P of zero will cause a crash with a source location rather
than an uninformative floating-point error or integer division by
zero signal.
Additional work is required in lowering to (1) pass source file path and
source line number arguments and (2) actually call these runtime
library APIs instead of emitting inline code for MOD &/or MODULO.
Differential Revision: https://reviews.llvm.org/D127034
Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.
flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.
Differential Revision: https://reviews.llvm.org/D109107
Move #include <complex.h> to complex-reduction.h, where
it is needed in MSVC builds.
Exclude code that requires a native 128-bit integer type from
compilation by MSVC.
Differential Revision: https://reviews.llvm.org/D99806
