The IOTYPE and V_LIST dummy arguments to a defined formatted I/O subroutine are extracted from a DT edit descriptor in a FORMAT. They are currently stored in the DataEdit structure, and their maximum sizes are rather small since DataEdits are sometimes returned or passed by value. This patch moves their storage into the FormattedIoStatementState structure and enlarges them a bit. Fixes https://github.com/llvm/llvm-project/issues/154954.
Whether list-directed child READ statements should be allowed to advance to further records is neither explicit in the standard nor consistent in existing Fortran implementations. We allow child namelist READ statements to advance, but not other list- directed child input. This patch refines our interpretation of this case. Child namelist READ statements continue to be able to advance; in addition, non-namelist child READ statements can now advance if their parent READ statement is a list-directed input statement at the top level, or a child that could. But non-namelist list-directed child input taking place in a context with explicit format control won't advance to following records, so that the format-controlled parent READ statement can retain control over record advancement. Also corrects two cases of record repositioning in numeric input editing, which were failing under child input because they weren't allowing for left tab limits. Fixes https://github.com/llvm/llvm-project/issues/160351.
We have some modifications downstream to compile the flang runtime for amdgpu using clang OpenMP, some more hacky than others to workaround (hopefully temporary) compiler issues. The additions here are the non-hacky alterations. Main changes: * Create freestanding versions of memcpy, strlen and memmove, and replace std:: references with these so that we can default to std:: when it's available, or our own Flang implementation when it's not. * Wrap more bits and pieces of the library in declare target wrappers (RT_* macros). * Fix some warnings that'll pose issues with werror on, in this case having the namespace infront of variables passed to templates. Another minor issues that'll likely still pop up depending on the program you're linking with is that abort will be undefined, it is perhaps possible to solve it with a freestanding implementation as with memcpy etc. but we end up with multiple definitions in this case. An alternative is to create an empty extern "c" version (which can be empty or forwrd on to the builtin). Co-author: Dan Palermo Dan.Palermo@amd.com
When somebody replaced uses of std::optional<> in the runtime with a new optional<> defined locally, many needless top-level Fortran:: namespace qualifiers were added, which are inconsistent with namespace usage in the runtime. Clean them up.
List-directed input statements maintain two flags ("eatComma_" and
"hitSlash_") in their state that allow GetNextDataEdit() to detect and
handle field separators (usually ',') and slashes in the input stream.
For list-directed input in a defined input subroutine, it's necessary to
copy those flags from the parent list-directed input statement (if any)
and update them afterwards.
Fixes https://github.com/llvm/llvm-project/issues/154791.
When NAMELIST input takes place on a derived type, we need to preserve the type in the descriptor that is created for storage sequence association. Further, the fact that any child list input in within the context of a NAMELIST must be inherited so that input fields don't try to consume later "variable=" strings. Fixes https://github.com/llvm/llvm-project/issues/151222.
Child I/O state needs to carry a pointer to the original non-type-bound defined I/O subroutine table, so that nested defined I/O can call those defined I/O subroutines. It also needs to maintain a mutableModes instance for the whole invocation of defined I/O, instead of having a mutableModes local to list-directed child I/O, so that a top-level data transfer statement with (say) DECIMAL='COMMA' propagates that setting down to nested child I/O data transfers. Fixes https://github.com/llvm/llvm-project/issues/149885.
Defined I/O subroutines have UNIT= and IOSTAT= dummy arguments that are required to have type INTEGER with its default kind. When that default kind is modified via -fdefault-integer-8, calls to defined I/O subroutines from the runtime don't work. Add a flag to the two data structures shared between the compiler and the runtime support library to indicate that a defined I/O subroutine was compiled under -fdefault-integer-8. This has been done in a compatible manner, so that existing binaries are compatible with the new library and new binaries are compatible with the old library, unless of course -fdefault-integer-8 is used. Fixes https://github.com/llvm/llvm-project/issues/148638.
When I/O list items include instances of derived types for which defined I/O procedures exist, ignore them. Fixes https://github.com/llvm/llvm-project/issues/144363.
Recursion, both direct and indirect, prevents accurate stack size calculation at link time for GPU device code. Restructure these recursive (often mutually so) routines in the Fortran runtime with new implementations based on an iterative work queue with suspendable/resumable work tickets: Assign, Initialize, initializeClone, Finalize, and Destroy. Default derived type I/O is also recursive, but already disabled. It can be added to this new framework later if the overall approach succeeds. Note that derived type FINAL subroutine calls, defined assignments, and defined I/O procedures all perform callbacks into user code, which may well reenter the runtime library. This kind of recursion is not handled by this change, although it may be possible to do so in the future using thread-local work queues. (Relanding this patch after reverting initial attempt due to some test failures that needed some time to analyze and fix.) Fixes https://github.com/llvm/llvm-project/issues/142481.