I want to be able to check if the storage is contiguous
in the innermost dimension, so I decided to add an entry point
that takes `dim` as the number of leading dimensions to check.
It seems that a runtime call might result in less code size
even when `dim` is 1, so here it is.
For opt-for-speed I am going to inline it in FIR.
Depends on #131047.
Flang's runtime can now be built using LLVM's LLVM_ENABLE_RUNTIMES
mechanism, with the intent to remove the old mechanism in #124126.
Update the pre-merge builders to use the new mechanism.
In the current form, #124126 actually will add
LLVM_ENABLE_RUNTIMES=flang-rt implicitly, so no change is strictly
needed. I still think it is a good idea to do it explicitly and in
advance.
On Windows, flang-rt also requires compiler-rt, but which is not
building on Windows anyway.
I thought I guessed a fix in #130836, but I was wrong.
We actually had the same code in
`flang/cmake/modules/FlangCommon.cmake`.
The check does not pass in flang-rt bootstrap build, because
`-nostdinc++` is added for all `runtimes` checks.
I decided to make the check with the C header, though, I am still
unsure whether it is reliable with a clang that has not been
installed (it is taken from the build structure during flang-rt
configure step).
I verified that this PR enables REAL(16) math entries on aarch64.
When compiling Flang-RT with Clang, query Clang for the GCC installation
it uses. If found, create `quadmath_wrapper.h` that points to the
`quadmath.h` of that GCC installation.
`quadmath.h` is only available when compiling with gcc, and Clang has no
equivalent even though gcc's version compiles fine with Clang (at least
up to and including gcc 13). It is still available into gcc's
installation resource dir (in constrast to a system-wide indirectory
such as `/usr/include` or `/usr/local/include`) and therefore not
available to any compiler other than the gcc of that installation.
quadmath may also be a different OS package than gcc itself, so it is
not necessarily presesent.
Clang actually already appropriates a GCC installation for its libraries
such that `libquadmath.a` is already found, but it does not do so for
the include paths. Because adding that directory to the header search
path may have wide-reaching consquences, we create only a wrapper header
that points to the real `quadmath.h` in the same GCC installation that
Clang uses.
This patch is to explicitly link the pthread library when building
shared flang-rt.
On AIX, for example, it needs to link in `libpthread.a` explicitly in
order to resolve the references to those `pthread_*` functions in
`include/flang-rt/runtime/lock.h`
pointer allocation is done through `AllocateValidatedPointerPayload`.
This function was not updated to use the registered allocators in the
descriptor to perform the allocation. This patch makes use of the
allocator.
The footer word is not set and not checked for allocator other than the
default one. The support will likely come in a follow up patch but this
will necessitate more functions to be registered to be able to set and
get the footer value when the allocation in on the device.
When reading an unformatted sequential file with variable-length
records, detect byte order reversal problems with the first record's
header and footer words, and emit a more detailed error message.
Make it possible to change the path used to install flang-rt library.
This is particularly necessary for standalone builds, where the CMake
script currently hardwires the default clang install path, and therefore
is incorrect for distributions that override it. However, for
consistency I have made it configurable unconditionally, preserving the
current defaults.
After commit b55f751, the flang-rt build on AIX is missing `-D_LARGE_FILE_API
-D_XOPEN_SOURCE=700` in compiling the source. This patch is to add the
compile definitions.
---------
Co-authored-by: Michael Kruse <github@meinersbur.de>
valgrind complained that `OpenStatementState::pathLength_` was used
before it was initialized, when a file was opened with
`status='scratch'`. The code seems to expect that `pathLengh_` should be
initialized to 0, so added default initialization to the declaration.
Under non-Windows platforms, also create a dynamic library version of
the runtime. Build of either version of the library can be switched on
using FLANG_RT_ENABLE_STATIC=ON respectively FLANG_RT_ENABLE_SHARED=ON.
Default is to build only the static library, consistent with previous
behaviour. This is because the way the flang driver invokes the linker,
most linkers choose the dynamic library by default, if available.
Building the dynamic library therefore causes flang-built executables to
depend on `libflang_rt.so`, unless explicitly told otherwise.
Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME
mechanism. It will only become active when
`LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the
`FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not
conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is
passed, nothing changes with the current build process.
Motivation:
* Consistency with LLVM's other runtime libraries (compiler-rt, libc,
libcxx, openmp offload, ...)
* Allows compiling the runtime for multiple targets at once using the
LLVM_RUNTIME_TARGETS configuration options
* Installs the runtime into the compiler's per-target resource directory
so it can be automatically found even when cross-compiling
Also see RFC discussion at
https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
There seems to be multiple declarations of __libcpp_verbose_abort, some
with noexcept and some without. Reverting to the previous
forward-declaration (without noexcept) which seemes to have worked
before.
Mostly mechanical changes in preparation of extracting the Flang-RT
"subproject" in #110217. This PR intends to only move pre-existing files
to the new folder structure, with no behavioral change. Common files
(headers, testing, cmake) shared by Flang-RT and Flang remain in
`flang/`.
Some cosmetic changes and files paths were necessary:
* Relative paths to the new path for the source files and
`add_subdirectory`.
* Add the new location's include directory to `include_directories`
* The unittest/Evaluate directory has unitests for flang-rt and Flang. A
new `CMakeLists.txt` was introduced for the flang-rt tests.
* Change the `#include` paths relative to the include directive
* clang-format on the `#include` directives
* Since the paths are part if the copyright header and include guards, a
script was used to canonicalize those
* `test/Runtime` and runtime tests in `test/Driver` are moved, but the
lit.cfg.py mechanism to execute the will only be added in #110217.
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
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
