libomp currently has two limitations:
1) although it's C++, it doesn't link against the C++ stdlib 2) it
cannot link against the implementation of LLVM ADTs
These limitations shall not be altered at the moment.
As a result, this commit introduces kmp_str_ref, which is similar to
LLVM's StringRef. It currently only includes methods I need at the
moment, but it's easily extensible.
The files omp_lib.h and omp-tools.h are the outputs of two
configure_file invocations which specify the full path of the outputs.
Use these full paths in LibompExports.cmake so they can actually be
found.
The previous attempt at this (b7da956501)
still broke standalone builds. Now I have locally tested standalone
flang, runtimes (with openmp), lldb, combined builds, and the utils
script. Hopefully that covers everything this time, and gets everything
into a more consistent state (always using the HandleDoxygen script in
the same way, included exactly once as required by the cmake design).
This patch prevents `omp_set_num_teams()` and
`omp_set_teams_thread_limit()` from updating teams-related ICVs when
called from restricted runtime contexts.
The non-implicit parallel-region case follows the OpenMP 5.1
restriction. The active `teams`-region case is handled defensively
because these ICVs are device-scoped and updating them during an active
`teams` region can affect later teams execution.
The calls now warn and return without updating the ICVs.
Fixes#194426.
Reverts llvm/llvm-project#191501 as cmake CI is having an issue with it:
```
-- Doxygen enabled (1.14.0).
CMake Error at /work/as-worker-4/publish-doxygen-docs/llvm-project/cmake/Modules/HandleDoxygen.cmake:29 (add_custom_target):
add_custom_target cannot create target "doxygen" because another target
with the same name already exists. The existing target is a custom target
created in source directory
"/work/as-worker-4/publish-doxygen-docs/llvm-project/llvm". See
documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
docs/CMakeLists.txt:59 (include)
```
Summary:
This PR cuts `flang` out of the core runtimes configure dependency. We
will need the runtimes infrastructure to handle `flang` module
generation, but this dependency poisons the entire dependency stack.
`flang` and `mlir` are by far the heavily parts of the LLVM stack and
for distribution we want to only build it when absolutely necessary,
which as of now is only to install flang module files.
The approach here is to simply remove the `flang` target from the core
dependency tree, but intead configure it for the top-level `module`
targets which are part of `all`. To make this work we need to pass
COMPILER_WORKS and set up a dummy location so that configuration passes.
it's a little backdoor, but this is an extremely important quality of
life improvement for LLVM distribution support.
This is to address the error appearing when building this code with
somewhat more recent compilers:
```
Use of undeclared identifier 'malloc'
```
Such inclusion has already been added to the OmptTester.cpp file.
Before this PR, omp_lib.h is emitted to `${PREFIX}/include` or
`${PREFIX}/lib/clang/<version>/include` (install prefix) and
`${PREFIX}/runtime/src/omp_lib.h` (builddir prefix). It is never found
there because the driver only adds `${PREFIX}/include/flang/OpenMP` to
the include path.
Fix the `omp_lib.h` include by using the same mechanism as the
omp_lib.mod; that is, move it to
`${PREFIX}/lib/clang/<version>/finclude/flang/<target-triple>`. The
search path is already added by the driver via
`-fintrinsics-modules-path` by the driver. Although omp_lib.h currently
does not contain anything target-specific, it could do so in the future
and I don't think it is worth the effort to add a mechanism without the
target triple. It should also me consistent with omp_lib.mod.
The changes in detail consist of:
1. Move the omp_lib.h output in the builddir to
`${RUNTIMES_OUTPUT_RESOURCE_MOD_DIR}`. This already takes care of
whether it is a bootstrapping build or not.
3. Move the omp_lib.h install dir to
`${RUNTIMES_INSTALL_RESOURCE_MOD_PATH}`.
4. Remove the implicit search path `include/flang/OpenMP` from the
frontend. There is nothing in there anyway.
5. Hardcoding the include search path for testing to the
`LLVM_RUNTIME_TARGETS=default` build becomes unnecessary. This was way
the `include-omp-header.f90` test was still passing, although it would
not work outside the regression tests. Essentially, it tested
lit.site.cfg, not the driver.
6. Replace the old `include-omp-header.f90` test. It created a temporary
`omp_lib.h` that interferes with any other test that use `include
omp_lib.h` (there currently isn't but I originally intended to add the
replacement as an additional omp_lib.h test which resulted in a flaky
test while the original test was there). Due to how the %flang(_fc1)
substitution works, lookup order may also vary.
Renames SphinxQuickstartTemplate.rst to SphinxQuickstartTemplate.md as
an isolated commit to preserve blame history. The file content is not
yet valid Markdown; the rewrite follows in a stacked PR.
Cross-references in MarkdownQuickstartTemplate.md, README.txt, and
openmp/docs/README.txt are updated accordingly.
See RFC:
https://discourse.llvm.org/t/rfc-make-myst-markdown-the-llvm-docs-format-rip-rest/90840
Working on enabling the build of OpenMP and Offload in pre-merge checks
surfaced this unused var and pre-merge checks run with -Werror.
As I did not see where it should be used, remove the variable to address
the warning.
The pre-merge running into the warning as error is
https://github.com/llvm/llvm-project/actions/runs/26826349862/job/79094823845?pr=174955
Reapplication of #137828 and #169638
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Constants such as `c_long_double` also have different
values).
Most other modules have `#ifdef`-enclosed code as well. For instance
this caused offload targets nvptx64-nvidia-cuda/amdgpu-amd-amdhsa to use
the modules files compiled for the host which may contrain uses of the
types REAL(10) or REAL(16) not available for nvptx/amdgpu.
2. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
Currently the dependencies between builtin modules and `omp_lib.mod`
seem to be incorrect:
https://github.com/llvm/llvm-project/pull/174474#issuecomment-3880189581
3. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted (PR
#169525).
If using Flang for cross-compilation or target-offloading, flang-rt must
now be compiled for each target not only for the library, but also to
get the target-specific module files. For instance in a bootstrapping
runtime build, this can be done by adding:
`-DLLVM_RUNTIME_TARGETS=default;nvptx64-nvidia-cuda;amdgpu-amd-amdhsa`.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Another subdirectory `flang` avoids accidental inclusion of
gfortran-modules which due to compression would result in
user-unfriendly errors. Now the driver adds `-fintrinsic-module-path`
for that location to the frontend call (Just like gfortran does).
Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
Summary:
This check exists to encode the policy that this is only intended to be
built with a just-built compiler. In practice it's a little too strict
and breaks pretty much every six months when the version bumps or when
people try to build a separate patch. Just demote to a warning.
Summary:
This target is missing, it's the expected behavior for all LLVM
components to have a way to install them individually as components.
This allows us to selectively install offload versus other pieces of the
runtime. Also make this and the openmp handling canonical with libcxx.
Summary:
This pattern is consistent throughout all the runtimes and is what the
top-level `install-openmp-<triple>` corresponds to. It should be
provided and used.
This fixes a warning in omptest about a set but unused variable. The var
was intended to control whether colored logging output is created.
That logic has been moved into the `Logger` itself.
PR #192687 Introduces a dependency to the Fortran intrinsic module when
building `openmp` Fortran modules, which requires a Flang enabled llvm
build in order to build `openmp` Fortran modules.
This PR is to add a cmake option `LIBOMP_FORTRAN_MODULES_ONLY` to allow
users to build 'openmp` Fortran modules only for Flang without building
the libomp runtime library.
This will allow libomp.a/so build still be independent from the Flang
build as before.
E.g. To build `openmp` Fortran modules only for Flang, one would need to
use the following options.
```
cmake \
...
-DLIBOMP_FORTRAN_MODULES_ONLY=ON \
-DLLVM_ENABLE_PROJECTS="flang" \
-DLLVM_ENABLE_RUNTIMES="openmp" \
...
Add new enum values, structs and variables to `omp-tools.h` header,
according to the OpenMP v6.0 specification.
Update `openmp` and `offload` tools headers to recognize the new values
to ease testing once those features are implemented.
Since no feature is implemented here, update the docs to mention
`partial` support, pointing to this PR for the enums.
---------
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
Summary:
This is used in the GPU portion of the build, but really shouldn't be.
Most of these helpers were only used by the GPU portion, which has much
nicer builtins available in new clang. Using these in the main offload
build is broken on Windows and not available on older compilers, so we
split. Also means one less header we share.
The alignment helpers are trivially replaced by an LLVM utility, the
only thing that remains are the pointer arithmetic functions. There's no
conveient place to put these so I just let them stay.
The OpenMP specification offers different ways for identifying the host
device. While users of the OpenMP API can use `omp_get_initial_device()`
or the constant `omp_initial_device` (available since OpenMP v5.2), a
tool needs to rely on the `initial_device_num` passed by the OpenMP
runtime during the `initialize` callback.
In #134451, it was discovered that the `initial_device_num` passed is
always `0`, regardless of any device are available for offload
execution. For host-only OpenMP code, this matches the result of
`omp_get_num_devices()`, and is a valid result. In the case of devices
being available though, this passed identifier is incorrect. While
`libomp` calls `omp_get_num_devices()`, `libomptarget` has not fully
initialized its PluginManager at that point, hence returning no
available devices. Tools relying on `initial_device_num` might therefore
incorrectly assume host-side execution when some code runs on a device.
Since the `ompt_get_num_devices()` entry point is also not fully
implemented, tools currently need to do on-the-fly handling for the host
device.
To make handling easier, consistently use the `omp_initial_device`
identifier as the `initial_device_num` and for all device callbacks.
This does not rely on knowing the number of available devices during
OMPT initialization in the runtime and ensures a consistent value for
tools to handle.
Closes#134451
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
When dladdr() fails, dl_info is left uninitialized. The code printed the
error but then fell through to unconditionally call
strrchr(dl_info.dli_fname, '/'), accessing an uninitialized pointer --
typically NULL on the stack -- causing a SIGSEGV.
Fix by turning the second 'if' into 'else if', so the path-extraction
block is only reached when dladdr() succeeded and dl_info is valid.
Assisted-by: Claude Sonnet 4.6
As per OpenMP 5.2/6.0 the below are valid device values in a `#pragma
omp target` directive:
omp_initial_device (-1) -> refers to the host CPU.
omp_invalid_device (-2) -> an intentionally invalid device, used to
trigger a runtime error.
For the 2 values discussed above flang fails with:
```
error: The device expression of the DEVICE clause must be a positive integer expression
!$OMP TARGET DEVICE(-1)
error: Must have INTEGER type, but is REAL(4)
!$OMP TARGET DEVICE(OMP_INVALID_DEVICE)
```
Issue: https://github.com/llvm/llvm-project/issues/192989
This patch renames the option to enable taskgraph support in the
runtime from OMPX_TASKGRAPH to OMP_TASKGRAPH_EXPERIMENTAL, to reflect
the feature's official status in OpenMP 6.0, but also the feature's
current work-in-progress nature.
commit-id:fa62775a
Reviewers: ro-i
Reviewed By: ro-i
Pull Request: https://github.com/llvm/llvm-project/pull/194045
The counterpart fix for clang (as too done here:
[flang-fix](https://github.com/llvm/llvm-project/pull/193669))
The incorrectly interpreted device values in the `target` directive
throws:
```
error: argument to 'device' clause must be a non-negative integer value
#pragma omp target device(-1)
^~
error: argument to 'device' clause must be a non-negative integer value
#pragma omp target device(omp_invalid_device)
^~~~~~~~~~~~~~~~~~
```
`__llvm_omp_indirect_call_lookup` takes in and returns a function
pointer, so make sure the types are correct, which includes the correct
address space.
The FE was recently changed to generate the correct code
[here](https://github.com/llvm/llvm-project/pull/192470).
With this change, three function pointer tests start passing.
Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
offload/cmake/caches/AMDGPUBot.cmake enables
RUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES="openmp". In that
sub-build, check-openmp target doesn't exist and there is build error
`unknown target 'check-openmp'` after 18f63d1375, which makes
top-level check-openmp depend on check-openmp-amdgcn-amd-amdhsa.
In openmp, the device targets only call add_subdirectory(device), which
doesn't calls construct_check_openmp_target() and check-openmp target
doesn't exist. `ninja check-openmp-amdgcn-amd-amdhsa` also fails with
the same error before 18f63d1375.
Fix by adding construct_check_openmp_target() for device targets as well.
Assisted-by: Claude Sonnet 4.6
On s390x, the changes to `control_tool.c` cause a different return
address to be returned from the call to `print_current_address(0)`. Due
to the strictness of the current address returned by this call, this
lead to a test failure.
Since the return values of `omp_control_tool` are checked in separate
tests already, revert the changes to ensure that the return address
stays at the expected value.
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
When a user calls `omp_control_tool`, a tool is attached and it
registered the `ompt_control_tool` callback, the tool should receive a
callback with the users arguments.
However, in #112924, it was discovered that this only happens after at
least one host side directive or runtime call calling into
`__kmp_do_middle_initialize` has been executed.
The check for `__kmp_init_middle` in `FTN_CONTROL_TOOL` did not try to
do the middle initialization and instead always returned `-2` (no tool).
A tool therefore received no callback. The user program did not get the
info that there is a tool attached. To fix this, change the explicit
return to a call of `__kmp_middle_initialize()`, as done in several
other places of `libomp`.
Further handling is then done in `__kmp_control_tool`, where the values
`-2` (no tool), `-1` (no callback), or the tools return value are
returned.
Also expand the tests to introduce checks where no callaback is
registered, or `omp_control_tool` is called before any OpenMP directive.
Fixes#112924
CC @jprotze, @hansangbae
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
