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.
Even after 13e2200fa4 (Solaris lacks
`femode_t`, too), the Solaris `flang` build is still broken:
```
/vol/llvm/src/llvm-project/local/flang/runtime/exceptions.cpp:87:5: error: static assertion failed due to requirement 'sizeof(fenv_t) <= sizeof(int) * 8': increase ieee_status_type size
87 | sizeof(fenv_t) <= sizeof(int) * _FORTRAN_RUNTIME_IEEE_FENV_T_EXTENT, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/llvm/src/llvm-project/local/flang/runtime/exceptions.cpp:87:20: note: expression evaluates to '200 <= 32'
87 | sizeof(fenv_t) <= sizeof(int) * _FORTRAN_RUNTIME_IEEE_FENV_T_EXTENT, | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This patch fixes this by removing the assertion.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
There was some confusion about units (bytes vs characters) in the
handling of the amount of input remaining in fixed-width formatted input
fields. Clarify that any variable or parameter counting "remaining"
space in a field in the I/O runtime is always in units of bytes, and
make it so where it wasn't.
Fixes the bug(s) in
llvm-test-suite/Fortran/gfortran/regression/char4_iunit_2.f03, although
the test still won't pass due to its dependence on gfortran's
list-directed output spacing.
The overflow check didn't work for a 27-digit octal field containing an
80-bit x87 extended precision real value. The count of bytes required
was too large because the leading digit (1) was assumed to require a
full three bits. And the actual transmission of the octal input digits
to the output buffer was incorrect, too.
Fixes llvm-test-suite/Fortran/gfortran/regression/boz_15.f90.
Most Fortran implementations support a READ statement after a WRITE
without repositioning on a sequential unit; it implies on ENDFILE and
then hits an EOF condition.
Fixes llvm-test-suite/Fortran/gfortran/regression/backspace_2.f.
… input
The current EOF detection method (IsAtEOF()) depends on comparing the
current record number with the record number of the endfile record, if
it is known, which it is for units that have been written and then
rewound for input. For formatted input, this is wrong in the case of a
unit written with in-band newline characters. Rather than scan output
data to count newlines, it's best to just organically determine EOF by
detecting a failed or short read(), as we would have done anyway had the
endfile record number not been known. (I considered resetting the
endfile record number at the point of a REWIND, but not all rewinds are
followed by input; it seems wiser to defer the resetting until an actual
READ takes place.)
Fixes llvm-test-suite/Fortran/gfortran/regression/backslash_2.f90
Lowering doesn't use it, and won't need it in the future; it emits
in-line code for conversions and for assignments to scalars, and uses
the general Assign() routine for arrays.
…was written
At the end of an internal output statement, The I/O runtime fills (the
remainder of) the current record with blanks if it's the only record or
if anything had been written to it. This turns out to be wrong in the
case of a format that ends with an explicit advance to the next record,
which needs to be cleared even if nothing has been written.
Fixes llvm-test-suite/Fortran/gfortran/regression/arrayio_1.f90.
After a non-advancing WRITE to a unit, ensure that any ENDFILE operation
(explicit or implicit) terminates the record. (All other Fortran
implementations do so except XLF.)
Fixes llvm-test-suite/Fortran/gfortran/regression/advance_6.f90.
A tricky case in Fw.d output editing is when the value needs to be
rounded either to a signed zero or away from zero to a power of ten
(1.0, 0.1, &c.). A bug report for LLVM on GitHub (#74274) exposed a bug
in this code in the case of Fw.0 editing where a value just over 0.5 was
rounded incorrectly to 0 rather than 1 when no fractional digits were
requested.
Rework that algorithm a little, ensuring that the initial
binary->decimal conversion produces at least one digit, and coping
correctly with the rounding of an exact 0.5 value for Fw.0 editing
(rounding it to the nearest even decimal, namely 0, following
near-universal compiler-dependent behavior in other Fortrans).
Fixes https://github.com/llvm/llvm-project/issues/74274.
The present implementation of defined formatted I/O is incorrect for
arrays in the data item list; it assumes that a DT defined format
descriptor (or list-directed/namelist instance) applies to all of the
elements in the array. The loop over the elements in the array is within
the DefinedFormattedIo() template function that handles defined
formatted I/O, not around its calls. This causes only one format list
edit descriptor to be used for the whole array, which is of course
wrong.
Invert this arrangment by performing the per-element looping in at the
top level in FormattedDerivedTypeIo() instead.
Defined unformatted I/O remains as it was.
Defined unformatted I/O is not allowed except from/to an external unit.
This restriction prohibits an INQUIRE(IOLENGTH=n) statement from using
derived types with defined unformatted output in its I/O list. The
runtime currently detects this case and crashes with an internal error;
this patch defines a new I/O error enum and causes the program to crash
with a more useful message.
On AIX malloc(0) reutrns nullptr, which fails test case
`Evaluate/ISO-Fortran-binding.test`, using malloc(1) in AIX for
consistent behaviour
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
AIX does not have `femode_t` in `<cfenv>` header, removing the assert to
fix build failures
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
As already documented in flang/docs/Extensions.md and implemented in the
compilation-time format validator, we want to support at execution time
the Intel (and presumably also Fujitsu) extension of allowing a missing
width on an edit descriptor in a formatted I/O statement.
Fixes https://github.com/llvm/llvm-project/issues/72597.
A subtle bug in buffer management is being caused by a WRITE on an
unformatted file with variable-length records after one or more
BACKSPACEs and some READs. An attempt at a minor optimization in
BACKSPACE kept the footer of the previous record in the unit's buffer,
in case more BACKSPACEs were to follow. If a later WRITE takes place
instead, the buffer's frame would still cover that footer, but its
content would be lost when the buffer became dirty on its first
modification, and the footer in the file would be overwritten with stale
buffer contents. As WriteFrame() implies the intent to define all the
bytes in the identified range, the trick being used in BACKSPACE with
its adjustment to frameOffsetInFile_ breaks any later WRITE... and so we
just can't do it.
Fixes https://github.com/llvm/llvm-project/issues/72599.
This update makes the user visible messages relating to features that
are not yet implemented be more consistent. I also cleaned up some of
the code.
For NYI messages that refer to intrinsics, I made sure the the message
begins with "not yet implemented: intrinsic:" to make them easier to
recognize.
I created some utility functions for NYI reporting that I put into
.../include/Optimizer/Support/Utils.h. These mainly convert MLIR types
to their Fortran equivalents.
I converted the NYI code to use the newly created utility functions.
This patch fixes a small bug where the new flang runtime types for
Windows (static, static_dbg, etc) are not built when the FortranRuntime
is requested by adding the missing dependency.
In Fortran, a format automatically repeats, with a line break, until all
the data items of a data transfer statement have been consumed. PRINT
"(3I4)", 1, 2, 3, 4, 5, 6 prints two lines, for example, three values
each.
When there are nested parentheses in a format, the rightmost set of
parentheses at the top level are used for automatic repetition. PRINT
"(I4,2(I4))" 1, 2, 3, 4, 5, 6, 7 print three lines, with three values on
the first and two each on the later ones.
Fix a bug in format interpretation that causes the detection of the
"rightmost" set of parentheses to take place on each pass, leading to
problems when parentheses are even further nested.
Currently flang's runtime libraries are only built for the specific CRT
that LLVM itself was built against. This patch adds the cmake logic for
building a separate runtime for each CRT configuration and adds a flag
for selecting a CRT configuration to link against.
…hecks
An OPEN statement on an existing unit can imply a CLOSE of that unit;
for example, OPEN(5, FILE="mydata", FORM="formatted") should implicitly
close the standard input that had been preconnected to unit 5. When this
happens, later checks in OPEN statement completion that apply only to
existing units should be disabled.
Changes in libc++ during the development cycle for LLVM 17 lead to the FortranRuntime library depending on libc++.
Trying to build with Flang 17 that was built with clang++ 17 and libc++ 17 (on MinGW) leads to the following linker error:
ld.lld: error: undefined symbol: std::__1::__libcpp_verbose_abort(char const*, ...)
>>> referenced by libFortranRuntime.a(io-api.cpp.obj):(std::__1::__throw_bad_variant_access[abi:v170000]())
>>> referenced by libFortranRuntime.a(io-stmt.cpp.obj)
>>> referenced by libFortranRuntime.a(unit.cpp.obj)
That might be caused by std::get being called on a std::variant in common::visit.
std::__libcpp_verbose_abort is a weak symbol in libc++ that can be optionally replaced by an alternative definition in user code (see: [1])
Do that to avoid a dependency of the FortranRuntime on libc++.
[1]: https://libcxx.llvm.org/UsingLibcxx.html#overriding-the-default-termination-handler
See also: https://github.com/msys2/MINGW-packages/pull/18002#issuecomment-1694412640
Differential Revision: https://reviews.llvm.org/D158957
Ensure that the f18Addendum flag is preserved in AllocatableApplyMold(),
that raw().type is reinitialized in AllocatableDeallocatePolymorphic(),
and that the implementations of SameTypeAs() and ExtendsTypeOf() handle
unallocated unlimited polymorphic arguments correctly.
A recent PR addressed zero and one element edge cases but did not cover
another case where the descriptors of arrays with more than two elements
may have byte strides that are not perfect multiples, like when creating
a descriptor for A(:, 1:1:2).
In general, the byte stride in a dimension is only meaningful if that
dimension has more than one element. Update IsContiguous and
CFI_is_contiguous to reflect that.
Support the EX edit descriptor for hexadecimal real formatted output and
hexadecimal real input for all forms of formatted input.. (We're
possibly the first Fortran compiler to support this feature for input
editing; only one other can handle EX output editing.)
As true (not BOZ) hexadecimal floating-point constants are not supported
in Fortran source code, only in formatted input, the implementation
takes place in the I/O editing portion of the runtime, not as new
conversions in the Decimal library.
…ent list
When a derived type value appears in NAMELIST input, its components'
values appear in sequence. This sequence can be truncated by a NAME=
that begins the next NAMELIST input item, or by the terminal '/' that
ends the NAMELIST group. Extend the mechanism already in place for
truncated array item lists in NAMELIST input so that it also applies to
derived type component sequences, and rename things appropriately.
The byte strides in zero and one element array descriptor may not be
perfect multiple of the element size and previous and extents.
IsContiguous and its CFI equivalent should still return true for such
arrays (Fortran 2018 standards says in 8.5.7 that an array is not
contiguous if it has two or more elements and ....).
This reverts commit 6403287eff.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
Example:
```
module types
type t
real,allocatable :: c
end type t
contains
function h(x)
class(t),allocatable :: h
...
end function h
subroutine test
type(t),allocatable :: b(:)
allocate(b(2),source=h(2.5))
end subroutine test7
end module type
```
`DoFromSourceAssign` creates two descriptors for initializing
`b(1)` and `b(2)` from the result of `h`. This Create call
creates a descriptor without properly initialized addendum,
so the Assign just does shallow copies of the descriptor
representing result of `h` into `b(1)` and `b(2)`.
I modified Create code to properly establish the descriptor
for derived type case.
I had to keep the `addendum` argument to keep the testing
in `flang/unittests/Runtime/TemporaryStack.cpp`.
I extended the "closure" of the device code containing the initial
transformational.cpp. The device side of the library should not be
complete at least for some APIs. For example, I tested with C OpenMP
code calling BesselJnX0 with a nullptr descriptor that failed with
a runtime error when executing on a GPU.
I added `--expt-relaxed-constexpr` for NVCC compiler to avoid multiple
warnings about missing `__attribute__((device))` on constexpr methods
coming from C++ header files.
Finalize/Initialize may be called on non contiguous arrays when dealing
with INTENT(OUT) dummies or non contiguous LHS. Update the related
element access to use indices instead of assuming contiguity and
manually computing the byte offset.
Also, the descriptor passed to parent type final routines should be set
to the parent type, otherwise descriptor.IsContiguous() may wrongfully
return true when finalizing parent components. Create a pointer to the
parent component when recursing in Finalize.
This set of commits resolves some of the issues with elemental calls producing
results that may require finalization, and also some memory leak issues due to
the missing deallocation of allocatable components of the temporary buffers
created by the bufferization pass.
- [flang][runtime] Expose Finalize API for derived types.
- [flang][hlfir] Add 'finalize' attribute for DestroyOp.
- [flang][hlfir] Postpone result finalization for elemental calls.
The results of elemental calls generated inside hlfir.elemental must not
be finalized/destructed before they are copied into the resulting
array. The finalization must be done on the array as a whole
(e.g. there might be different scalar and array finalization routines).
The finalization work is left to the hlfir.destroy corresponding
to this hlfir.elemental.
- [flang][hlfir] Tighten requirements on hlfir.end_associate operand.
If component deallocation might be required for the operand of
hlfir.end_associate, we have to be able to get the variable
shape/params to create a descriptor for calling the runtime.
This commit adds verification that we can do so.
- [flang][hlfir] Lower argument clean-ups using valid hlfir.end_associate.
The operand must be a Fortran entity, when allocatable component
deallocation may be required.
- [flang][hlfir] Properly clean-up temporary buffers in bufferization pass.
This commit combines changes for proper finalization and component
deallocation of the temporary buffers. The finalization part
relates to hlfir.destroy operations with 'finalize' attribute.
The component deallocation might be invoked for both hlfir.destroy
and hlfir.end_associate, if the operand is of a derived type
with allocatable component(s).
The changes are mostly in one function, so I decided not to split them.
- [flang][hlfir] Disable optimizations for hlfir.elemental requiring finalization.
If hlfir.elemental is coupled with hlfir.destroy with 'finalize' attribute,
the temporary array result of hlfir.elemental needs to be created
for the purpose of finalization. We cannot do certain optimizations
on such hlfir.elemental operations.
I was not able to come up with a test for the OptimizedBufferization pass,
but I put the check there as well.
Previous code was finalizing polymorphic components according to static
type (calling the static type final routine, if any).
There is no way (I think) to know from a
Fortran::runtime::typeInfo::Component if an allocatable component is
polymorphic or not. So this patch just always uses the dynamic type
descriptor to check for derived type allocatable component finalization.
…lues
Emit an error at runtime when a list-directed input value is not
followed by a value separator or end of record. Previously, the runtime
I/O library was consuming as many input characters that were valid for
the type of the value, and leaving any remaining characters for the next
input edit, if any.
Source allocation with a zero sized array is legal, and the resulting
allocatable/pointer should be allocated/associated.
The current code skipped the actual allocation, leading the allocatable
or pointer to look unallocated/disassociated.
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
