-isysroot flag was added to all tests, but it makes
Driver/darwin-version.f90 failed.
In fact, only a few tests regarding interoperability with C need
-isysroot flag to search for headers and libraries. So, -isysroot flag
is now eliminated from the substitution `%flang`, and a new substitution
`%isysroot` has been introduced.
Moreover, Integration/iso-fortran-binding.cpp invokes clang++ via a
shell script, which makes it hard to add -isysroot flag. So, it is
refactored.
Fixes#150765
Add a comment explaining why intrinsic derived type assignment
unconditionally deallocates all allocated allocatable subobject
components of the left-hand side variable, so that I won't forget the
reasoning here the next time this comes into question.
The various per-type functions for list-directed (including namelist)
input editing all call a common function to detect whether the next
token of input is the name of a namelist item. This check simply
determines whether this next token looks like an identifier followed by
'=', '(', or '%', and this fails when the next item of input is a NAN
with parenthesized stuff afterwards. Make the check smarter so that it
ensures that any upcoming possible identifier is actually the name of an
item in the namelist group. (And that's tricky too when the group has an
array item named "nan" and the upcoming input is "nan("; see the
newly-added unit test case.)
Fixes https://github.com/llvm/llvm-project/issues/152538.
more
Currrently flang-rt assumes that LLVM was always built with the dynamic
MSVC runtime. This may not be the case, if the user has specified a
different runtime with -DCMAKE_MSVC_RUNTIME_LIBRARY. Since this flag is
implied by -DLLVM_ENABLE_RPMALLOC=On, which is used by the Windows
release script, this is causing that script to fail.
Fixes#151920
Until the compiler part is fully hooked up via
https://github.com/llvm/llvm-project/pull/151878, tested this using
`external`:
```
external secnds
real s1, s2
s1 = secnds(0.0)
print *, "Seconds from midnight:", s1
call sleep(2)
s2 = secnds(s1)
print *, "Seconds from s1", s2
print *, "Seconds from midnight:", secnds(0.0)
end
```
InputNamelist() returns early if any value list read in by
InputDerivedType() or DescriptorIo<Input>() is empty, since they return
false. But an empty value list is okay, and the early return should
occur only on error.
Fixes https://github.com/llvm/llvm-project/issues/151756.
For more accurate compatibility with other compilers' extensions, accept
a bare exponent letter as valid real input to a formatted READ statement
only in a fixed-width input field. So it works with (G1.0) editing, but
not (G)/(D)/(E)/(F) or list-directed input.
Fixes https://github.com/llvm/llvm-project/issues/151465.
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.
As a common extension, we support the truncation of fixed-width fields
for non-list-directed input editing when a separator character (',' or
';' depending on DECIMAL='POINT' or 'COMMA' resp.) appears in the field.
This isn't working for L input editing; fix.
(The bug reports a failure with DC mode, but it doesn't work with a
comma either.)
Fixes https://github.com/llvm/llvm-project/issues/151178.
The assignment to mutableModes() in BeginIoStatement() is redundant,
since the mutableModes_ data member is initialized by the constructors
of the two classes that now have one. Remove the assignment to avoid
confusion.
Also restores the original OutputStatementState base class name after a
recent patch that needlessly changed it to something equivalent but less
readable.
Flang and Flang-RT have two flavours of unittests:
1. GTest unittests, using lit's `lit.formats.GoogleTest` format ending
with `Tests${CMAKE_EXECUTABLE_SUFFIX}`
2. "non-GTest" or "OldUnit" unittests, a plain executable ending with
`.test${CMAKE_EXECUTABLE_SUFFIX}`
Both executables are emitted into the same unittests/ subdirectory. When
running ...
1. `tests/Unit/lit.cfg.py`, only considers executable ending with
`Tests` (or `Tests.exe` on Windows), hence skips the non-GTest tests.
2. `tests/NonGtestUnit/lit.cfg.py` considers all tests ending with
`.test` or `.exe`. On Windows, The GTest unitests also end with `.exe`.
In Flang-RT, `.exe` is considered an extension for non-GTest unitests
which causes tests such as Flang's `RuntimeTests.exe` to be executed for
both on Windows. This particular test includes a file write test, using
a hard-coded filename `ucsfile`. If the two instances are executed
concurrently, they might interfere with each other reading/writing
`ucsfile` which results in a flaky test.
This patch avoids the redundant execution by requiring the suffix
`.test.exe` on Windows. lit has to be modified because it uses
`os.path.splitext` the extract the extension, which would only recognize
the last component. It was changed from the orginal `endswith` in
c865abe747aa72192f02ebfdcabe730f2553e42f
for unknown reasons.
In Flang, `.exe` is not considered a suffix for non-GTest unittests and
hence they are not run at all. Fixing by also added `.test.exe` as valid
suffix, like with Flang-RT.
Unfortunately, the ` Evaluate/real.test.exe` test was failing on
Windows:
```
FAIL: flang-OldUnit :: Evaluate/real.test.exe (3592 of 3592)
******************** TEST 'flang-OldUnit :: Evaluate/real.test.exe' FAILED ********************
..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10
0 0x800001 * 0xbf7ffffe
..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10
0 0x800001 * 0x3f7ffffe
..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10
0 0x80800001 * 0xbf7ffffe
..\_src\flang\unittests\Evaluate\real.cpp:511: FAIL: FlagsToBits(prod.flags) == 0x18, not 0x10
0 0x80800001 * 0x3f7ffffe
...
```
This is due to the `__x86_64__` macro not being set by Microsoft's
cl.exe and hence floating point status flags not being read out. The
equivalent macro for Microsofts compiler is `_M_X64` (or `_M_X64`).
This fixes an issue where if the build folder is no longer present flang
cannot link anything on Windows because the path to compiler-rt in the
binary is hard-coded. Flang already links compiler-rt on Windows so it
isn't necessary for flang-rt to specify that it depends on compiler-rt
at all, other than for the unit tests, so instead we can move that logic
into the unit test compile lines.
Formatted input of real values can handle a ',' field separator when one
appears in an fixed-width input field, but can't cope with a semicolon
under DECIMAL='COMMA'. Fix.
Fixes https://github.com/llvm/llvm-project/issues/150047.
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.
Fix issue reported in #150136. `createAllocatable` returns an OwingPtr.
Use `get()` to get the raw pointer has it is done in the
`flang-rt/unittests/Runtime/CUDA/Memory.cpp` tests.
Pointer remappings unconditionally update the element byte size and
derived type of the pointer's descriptor. This is okay when the pointer
is polymorphic, but not when a pointer is associated with an extended
type.
To communicate this monomorphic case to the runtime, add a new entry
point so as to not break forward binary compatibility.
…d complex input
List-directed reads of complex values that can't go through the usual
fast path (as in this bug's test case, which uses DECIMAL='COMMA')
didn't skip spaces before the closing right parenthesis correctly.
Fixes https://github.com/llvm/llvm-project/issues/149164.
This patch avoids a trip through the work queue engine for cases on a
CPU where finalization and destruction actions during assignment were
handled without enqueueing another task.
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.
Rework derived type initialization in the runtime to just initialize the
first element of any array, and then memcpy it to the others, rather
than exercising the per-component paths for each element.
Reword derived type destruction in the runtime to detect and exploit a
fast path for allocatable components whose types themselves don't need
nested destruction.
Small tweaks were made in hot paths exposed by profiling in descriptor
operations and derived type assignment.
After the recent move to work queues, in certain cases when linking in
the fortran runtime built for offload on AMDGPU as required in certain
cases, we'll get missing symbols when linking. This PR tries to address
this issue by encompassing more of the library in
RT_OFFLOAD_API_GROUP_BEGIN, which has the affect of compiling these
functions for AMDGPU, resolving the missing symbols.
This PR should address the following issue:
https://github.com/llvm/llvm-project/issues/145888
Followup to https://github.com/llvm/llvm-project/pull/143508
This required adding another alternative implementation of time
intrinsics to match what is available in older MacOS.
With this change, flang can be used to build programs for older versions
of MacOS.
Co-authored-by: David Truby <david.truby@arm.com>
The Offload and Flang-RT had the ability to compile GTest themselves.
But in bootstrapping builds, LLVM_LIBRARY_OUTPUT_INTDIR points to the
same location as the stage1 build. If both are building GTest, they
everwrite each others `libllvm_gtest.a` and `libllvm_test_main.a` which
causes #143134.
This PR removes the ability for the Offload/Flang-RT runtimes to build
their own GTest and instead relies on the stage1 build of GTest. This
was already the case with LLVM_INSTALL_GTEST=ON configurations. For
LLVM_INSTALL_GTEST=OFF configurations, we now also export gtest into the
buildtree configuration. Ultimately, this reduces combinatorial
explosion of configurations in which unittests could be built
(LLVM_INSTALL_GTEST=ON, GTest built by Offload, GTest built by Flang-RT,
GTest built by Offload and also used by Flang-RT).
GTest and therefore Offload/Runtime unittests will not be available if
the runtimes are configured against an LLVM install tree. Since llvm-lit
isn't available in the install tree either, it doesn't matter.
Note that compiler-rt and libc also use GTest in non-default
configrations. libc also depends on LLVM's GTest build (and would
error-out if unavailable), but compiler-rt builds it completely
different.
Fixes#143134
The recent change of `flang-rt` has code like `std::size_t
offset{offset_};`.
It broke the 32-bit `flang-rt` build because `Component::offset_` is of
type `uint64_t` but `size_t` varies.
Clang complains
```
error: non-constant-expression cannot be narrowed from type 'std::uint64_t' (aka 'unsigned long long') to 'std::size_t' (aka 'unsigned long') in initializer list [-Wc++11-narrowing]
143 | std::size_t offset{offset_};
| ^~~~~~~
```
This patch is to use the consistent `uint64_t` for offset.
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.
The SOURCE= expression of an ALLOCATE statement, when present and not
scalar, must conform to the shape of the allocated objects. Check this
at runtime, and return a recoverable error, or crash, when appropriate.
Fixes https://github.com/llvm/llvm-project/issues/143900.
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.
The effects of this restructuring on CPU performance are yet to be
measured.
In a test like:
```
integer, allocatable, device :: da(:)
allocate(a(200))
a = 2
da = a ! da is not allocated before data transfer is initiated. Allocate it with a
```
The reference compiler will allocate the data for the `da` descriptor so
the data transfer can be done properly.
When an assignment to a derived type allocatable requires
(re)allocation, its type may change to that of the right-hand side. The
code didn't update its derived type pointer, leading to the wrong type
being put into the descriptors created for elemental defined assignment
subroutine calls.
Fixes https://github.com/llvm/llvm-project/issues/141835.
FORMAT("J=",I3) is accepted by a few other Fortran compilers as a valid
format for input as well as for output. The character string edit
descriptor "J=" is interpreted as if it had been 2X on input, causing
two characters to be skipped over. The skipped characters don't have to
match the characters in the literal string. An optional warning is
emitted under control of the -pedantic option.
Not explicitly defining the default case for ShallowCopy* functions does
not meet the requirements for gcc to actually instantiate the templates,
leading to build errors that show up with gcc but not with clang.
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
Using Descriptor.Element<>() when iterating through a rank-1 array is
currently inefficient, because the generic implementation suitable for
arrays of any rank makes the compiler unable to perform optimisations
that would make the rank-1 case considerably faster.
This is currently done inside ShallowCopy, as well as by CopyInAssign,
where the implementation of elemental copies (inside Assign) is
equivalent to ShallowCopyDiscontiguousToDiscontiguous.
To address that, add a DescriptorIterator abstraction specialised for
arrays of various ranks, and use that throughout ShallowCopy to iterate
over the arrays.
Furthermore, depending on the pointer type passed to memcpy, the
optimiser can remove the memcpy calls from ShallowCopy altogether which
can result in substantial performance improvements on its own.
Specialise ShallowCopy for various element pointer types to make these
optimisations possible.
Finally, replace the call to Assign inside CopyInAssign with a call to
newly optimised ShallowCopy.
For the thornado-mini application, this reduces the runtime by 27.7%.
---------
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
