j0l, j1l, jnl, y0l, y1l and ynl are glibc extensions rather than
standard POSIX functions, and so are not available in every Linux libc.
This patch checks if `__GLIBC__` and `_GNU_SOURCE` are defined before
using
these functions.
This patch allows the float128 runtime to build with musl libc on Linux.
Move the ErfcScaled template function from the runtime into a new header
file in flang/include/Common, then use it in constant folding to
implement folding for the erfc_scaled() intrinsic function.
When an OPEN statement with a unit number fails in a recoverable manner,
the runtime needs to delete the ExternalFileUnit instance that was
created in the unit map. And we do this too soon -- that instance still
holds some of the I/O statement state that will be used by a later call
into the runtime for EndIoStatement.
Move the code that deletes the unit after a failed but recoverable OPEN
into ExternalIoStatementBase::EndIoStatement, and don't do things
afterwards that would need the I/O statement state that has been
destroyed.
Fixes https://github.com/llvm/llvm-project/issues/111404.
This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.
---------
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
IEEE_RINT rounds a real value to an integer-valued real.
IEEE_INT rounds a real value to an integer value.
The primary IEEE_INT result is generated with a call to IEEE_RINT.
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These are used in
some legacy codes such as libexodus.
All the above compilers accept using MALLOC and FREE with integers as
well, despite that this will often signify a bug in user code. We should
accept the same as the other compilers for compatibility.
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
---------
Co-authored-by: Yi Wu <yi.wu2@arm.com>
When compiling on aarch64 some `LDBL_MANT_DIG == 113` entries
end up trying to use `complex<long double>` for which there are
no certain specializations in `libcudacxx`. This change-set
includes a clean-up for `LDBL_MANT_DIG == 113` usage, which is replaced
with `HAS_LDBL128` that is set in `float128.h`.
This patch adds new runtime entry points that perform the simple
allocation/deallocation of module allocatable variable with cuda
attributes.
When the allocation is initiated on the host, the descriptor on the
device is synchronized. Both descriptors point to the same data on the
device.
This is the first PR of a stack.
`std::complex` operators do not work for the CUDA device compilation
of F18 runtime. This change makes use of `cuda::std::complex` from
`libcudacxx`.
`cuda::std::complex` does not have specializations for `long double`,
so the change is accompanied with a clean-up for `long double` usage.
Additional change on top of #109078 is to use `cuda::std::complex`
only for the device compilation, otherwise the host compilation
fails because `libcudacxx` may not support `long double` specialization
at all (depending on the compiler).
When an OPEN statement fails, a unit that was created for the OPEN needs
to be removed from the unit map. The code that tried to do this was
incorrect -- it needs to re-acquire the unit via LookUpForClose as a
CLOSE statement does. (The failure to do this completely was leaving a
zombie unit active that could break a later OPEN on the same unit
number.)
`std::complex` operators do not work for the CUDA device compilation
of F18 runtime. This change makes use of `cuda::std::complex` from
`libcudacxx`.
`cuda::std::complex` does not have specializations for `long double`,
so the change is accompanied with a clean-up for `long double` usage.
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.
Add new entry points for more complex data transfer involving
descriptors. These functions will be called when converting
`cuf.data_transfer` operations.
When building FortranRuntime out of tree on aarch64, the list of include
directories for the files comming from FortranFloat128MathILib
has to contain flang/runtime. I did this via
INTERFACE_INCLUDE_DIRECTORIES property.
A few other Fortran compilers silently accept real values for integer
variables in NAMELIST input. Handling an exponent would be difficult,
but it's easy to skip and ignore a fractional part when one is present.
A defined assignment generic interface for a given LHS/RHS type & rank
combination may have a specific procedure with LHS dummy argument that
is neither allocatable nor pointer, or specific procedure(s) whose LHS
dummy arguments are allocatable or pointer. It is possible to have two
specific procedures if one's LHS dummy argument is allocatable and the
other's is pointer.
However, the runtime doesn't work with LHS dummy arguments that are
allocatable, and will crash with a mysterious "invalid descriptor" error
message.
Extend the list of special bindings to include
ScalarAllocatableAssignment and ScalarPointerAssignment, use them when
appropriate in the runtime type information tables, and handle them in
Assign() in the runtime support library.
When scanning ahead for the first character in the next input item in
list-directed internal input, allow a newline character to appear and
treat it as a space, matching the behavior of nearly all other Fortran
compilers.
Don't require the "VALUES=" argument to the extension intrinsic
procedure ETIME to have exactly two elements. Other compilers that
support ETIME do not, and it's easy to adapt the behavior to whatever
the dynamic size turns out to be.
Add runtime APIs for the intrinsic function SPACING for REAL kinds 2 & 3
in two ways: Spacing2 (& 3) for build environments with std::float16_t,
and Spacing2By4 (& 3By4) variants (for any build environment) which
compute SPACING for those types but accept and return their values as
32-bit floats.
SPACING for REAL(2) is needed by HDF5.
The initial seed was generated from a bitwise AND ("&") of two
clock-generated values, instead of an XOR or (best) a truncated integer
multiplication. Maybe I mistyped a shift-7 instead of a shift-6 or
shift-8 when I wrote that line, but it was most likely just stupidity.
Fixes https://github.com/llvm/llvm-project/issues/106221.
Currently, strftime is called to get the timezone for the ZONE argument.
On AIX, this routine requires an environment variable set in order to
return the required format. This patch is to add the time difference
computation from UTC for the platform.
Add extended versions of SELECTED_INT_KIND and SELECTED_REAL_KIND
runtime APIs that permit lowering to pass along a bit mask of acceptable
kinds. The existing APIs call the new ones with a full bit mask. If
lowering transitions to always use the new APIs the old ones can then be
deleted.
Allow a runtime build to disable SELECTED_REAL_KIND from returning kind
3 (16-bit truncated form of 32-bit IEEE-754 floating point, a/k/a "brain
float" or bfloat16).
…tValue
Current choice was only working out of accident on 64 bit machine, it
led to an implicit cast to smaller type on 32 bit machine. Use the exact
type instead.
Add FLANG_RUNTIME_NO_INTEGER_16 and FLANG_RUNTIME_NO_REAL_{2,10,16} to
allow one to disable those kinds from being returned from
SELECTED_INT_KIND and SELECTED_REAL_KIND even if they are actually
available in the C++ build compiler.
According to the C99 standard, <fenv.h> may not define FE_INVALID and
the likes. Even if C++11 mandate them, musl and emscripten don't provide
them, so handle that case.
CUDA Fortran is meant to be an equivalent to the runtime API. Therefore,
it makes more sense to use the cuda rt API in the allocators for CUF.
@bdudleback
