Michael Kruse 87cbea6cdc
[openmp][cmake][NFCI] Avoid non-eval uses of ${var} (#182267)
When using

    set(var "Example")
    if (${var})

CMake will first resolve the if-argument to

    if (Example)

And what then happens depends on the existance of a variable with the
name "Example":

1. If instead of "Example", a truth constant is used ("TRUE", "FALSE",
   "ON", "OFF", "", "-NOTFOUND" ...), it is prioritized
   (https://cmake.org/cmake/help/latest/command/if.html#constant)

2. If a variable with the name "Example" exists: Use the truthiness of
   its content
   (https://cmake.org/cmake/help/latest/command/if.html#variable)

3. Otherwise, it is false-y

That is, the the result of the conditional does not only depend on the
content of `var`, but also some other variable. This is usually
unintended and leads to problems such as addressed with #154537. The
only case where this is intended is when passing an expression to be
evaluated such as with `pythonize_bool`, `append_if` and
`libomp_append`. In all other cases, using `${var}` without quotes is a
pattern to be avoided.

Remark:
If `${var}` is not one of the values considered a [truthiness
constant](https://cmake.org/cmake/help/latest/command/if.html#constant),
the result of `if (var)` and `if ("${var}")` is different:

* `if (var)` is true-ish
  (https://cmake.org/cmake/help/latest/command/if.html#variable)

* `if ("Example")` and therefore `if ("${var}")` are false-y
  (https://cmake.org/cmake/help/latest/command/if.html#string)

In this PR I am preferring `if (var)` over `if ("${var}")` because has
less clutter, resembles Python's behaviour, and problably what most
users are expecting, even though `if (${var})` in most cases would
evaluate to false-y because a variable does not exist. This ambiguity
does not exist for STREQUAL and MATCHES.
2026-03-02 13:21:36 +01:00
..

               README for the LLVM* OpenMP* Runtime Library
               ============================================

How to Build Documentation
==========================

The main documentation is in Doxygen* format, and this distribution
should come with pre-built PDF documentation in doc/Reference.pdf.
However, an HTML version can be built by executing:

% doxygen doc/doxygen/config

in the runtime directory.

That will produce HTML documentation in the doc/doxygen/generated
directory, which can be accessed by pointing a web browser at the
index.html file there.

If you don't have Doxygen installed, you can download it from
www.doxygen.org.


How to Build the LLVM* OpenMP* Runtime Library
==============================================

For build instructions, please see https://openmp.llvm.org/Building.html.


Architectures Supported
=======================
* IA-32 architecture
* Intel(R) 64 architecture
* Intel(R) Many Integrated Core Architecture
* ARM* architecture
* Aarch64 (64-bit ARM) architecture
* IBM(R) Power architecture (big endian)
* IBM(R) Power architecture (little endian)
* IBM(R) Z (s390x) architecture
* MIPS and MIPS64 architecture
* RISCV64 architecture
* LoongArch64 architecture

Supported RTL Build Configurations
==================================

Supported Architectures: IA-32 architecture, Intel(R) 64, and
Intel(R) Many Integrated Core Architecture

              ----------------------------------------------
              |   icc/icl     |    gcc      |   clang      |
--------------|---------------|----------------------------|
| Linux* OS   |   Yes(1,5)    |  Yes(2,4)   | Yes(4,6,7)   |
| FreeBSD*    |   No          |  No         | Yes(4,6,7,8) |
| OS X*       |   Yes(1,3,4)  |  No         | Yes(4,6,7)   |
| Windows* OS |   Yes(1,4)    |  No         | No           |
------------------------------------------------------------

(1) On IA-32 architecture and Intel(R) 64, icc/icl versions 12.x are
    supported (12.1 is recommended).
(2) GCC* version 4.7 is supported.
(3) For icc on OS X*, OS X* version 10.5.8 is supported.
(4) Intel(R) Many Integrated Core Architecture not supported.
(5) On Intel(R) Many Integrated Core Architecture, icc/icl versions 13.0
    or later are required.
(6) Clang* version 3.3 is supported.
(7) Clang* currently does not offer a software-implemented 128 bit extended
    precision type.  Thus, all entry points reliant on this type are removed
    from the library and cannot be called in the user program.  The following
    functions are not available:
    __kmpc_atomic_cmplx16_*
    __kmpc_atomic_float16_*
    __kmpc_atomic_*_fp
(8) Community contribution provided AS IS, not tested by Intel.

Supported Architectures: IBM(R) Power 7 and Power 8

              -----------------------------
              |   gcc      |   clang      |
--------------|------------|--------------|
| Linux* OS   |  Yes(1,2)  | Yes(3,4)     |
-------------------------------------------

(1) On Power 7, gcc version 4.8.2 is supported.
(2) On Power 8, gcc version 4.8.2 is supported.
(3) On Power 7, clang version 3.7 is supported.
(4) On Power 8, clang version 3.7 is supported.


Front-end Compilers that work with this RTL
===========================================

The following compilers are known to do compatible code generation for
this RTL: clang (from the OpenMP development branch at
http://clang-omp.github.io/ ), Intel compilers, GCC.  See the documentation
for more details.

-----------------------------------------------------------------------

Notices
=======

*Other names and brands may be claimed as the property of others.