Cold-Air-Networks/mirror-llvm-project
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 7
mirror-llvm-project/openmp/cmake/modules/LibompHandleFlags.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

188 lines
8.5 KiB
CMake
Raw Normal View History

Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
#
#//===----------------------------------------------------------------------===//
#//
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2019-01-19 01:56:40 -09:00
#// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
#// See https://llvm.org/LICENSE.txt for license information.
#// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
#//
#//===----------------------------------------------------------------------===//
#
# Setup the flags correctly for cmake (covert to string)
# Pretty them up (STRIP any beginning and trailing whitespace,
# remove duplicates, remove empty entries)
macro(libomp_setup_flags flags)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
if(NOT "${${flags}}" STREQUAL "") # if flags are empty, don't do anything
set(flags_local)
list(REMOVE_DUPLICATES ${flags}) # remove duplicates
list(REMOVE_ITEM ${flags} "") # remove empty items
libomp_list_to_string("${${flags}}" flags_local)
string(STRIP "${flags_local}" flags_local)
set(${flags} "${flags_local}")
endif()
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endmacro()
[OpenMP] Turn on -Wall compiler warnings by default Instead, maintain a list of disabled options to still build libomp and libomptarget without warnings. This includes -Wno-error and -Wno-pedantic to silence warnings that LLVM enables when building in-tree. I tested the following compilers: * Clang 6.0, 7.0, 8.0 * GCC 4.8.5 (CentOS 7), GCC 6, 7, 8, 9 * Intel Compiler 16, 17, 18, 19 RFC thread on openmp-dev mailing list: http://lists.llvm.org/pipermail/openmp-dev/2019-August/002668.html Differential Revision: https://reviews.llvm.org/D65867 llvm-svn: 368999
2019-08-15 05:11:50 -08:00
# C++ compiler flags
function(libomp_get_cxxflags cxxflags)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(flags_local)
[OpenMP] Fix detecting warning options for GCC If testing for a warning option like -Wno-<foo> with GCC, GCC won't print any diagnostic at all, leading to the options being accepted incorrectly. However later, if compiling a file that actually prints another warning, GCC will also print warnings about these -Wno-<foo> options being unrecognized. This avoids warning spam like this, for every OpenMP source file that produces build warnings with GCC: cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’ cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’ cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’ cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’ This matches how such warning options are detected and added in llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this: check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG) append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS) This also matches how LLDB warning options were restructured for GCC compatibility in e546bbfda0ab91cf78c096d8c035851cc7c3b9f3. Differential Revision: https://reviews.llvm.org/D139922
2022-12-13 00:39:27 -09:00
# GCC silently accepts any -Wno-<foo> option, but warns about those options
# being unrecognized only if the compilation triggers other warnings to be
# printed. Therefore, check for whether the compiler supports options in the
# form -W<foo>, and if supported, add the corresponding -Wno-<foo> option.
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(flags_local -fno-exceptions LIBOMP_HAVE_FNO_EXCEPTIONS_FLAG)
Introduce dynamic affinity dispatch capabilities This set of changes enables the affinity interface (Either the preexisting native operating system or HWLOC) to be dynamically set at runtime initialization. The point of this change is that we were seeing performance degradations when using HWLOC. This allows the user to use the old affinity mechanisms which on large machines (>64 cores) makes a large difference in initialization time. These changes mostly move affinity code under a small class hierarchy: KMPAffinity class Mask {} KMPNativeAffinity : public KMPAffinity class Mask : public KMPAffinity::Mask KMPHwlocAffinity class Mask : public KMPAffinity::Mask Since all interface functions (for both affinity and the mask implementation) are virtual, the implementation can be chosen at runtime initialization. Differential Revision: https://reviews.llvm.org/D26356 llvm-svn: 286890
2016-11-14 12:08:35 -09:00
libomp_append(flags_local -fno-rtti LIBOMP_HAVE_FNO_RTTI_FLAG)
[OpenMP] Fix detecting warning options for GCC If testing for a warning option like -Wno-<foo> with GCC, GCC won't print any diagnostic at all, leading to the options being accepted incorrectly. However later, if compiling a file that actually prints another warning, GCC will also print warnings about these -Wno-<foo> options being unrecognized. This avoids warning spam like this, for every OpenMP source file that produces build warnings with GCC: cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’ cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’ cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’ cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’ This matches how such warning options are detected and added in llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this: check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG) append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS) This also matches how LLDB warning options were restructured for GCC compatibility in e546bbfda0ab91cf78c096d8c035851cc7c3b9f3. Differential Revision: https://reviews.llvm.org/D139922
2022-12-13 00:39:27 -09:00
libomp_append(flags_local -Wno-class-memaccess LIBOMP_HAVE_WCLASS_MEMACCESS_FLAG)
libomp_append(flags_local -Wno-covered-switch-default LIBOMP_HAVE_WCOVERED_SWITCH_DEFAULT_FLAG)
libomp_append(flags_local -Wno-frame-address LIBOMP_HAVE_WFRAME_ADDRESS_FLAG)
libomp_append(flags_local -Wno-strict-aliasing LIBOMP_HAVE_WSTRICT_ALIASING_FLAG)
[CMake] Disable -Wstringop-overflow GCC 8 produces false-positives with this: In file included from <openmp>/src/runtime/src/kmp_os.h:950, from <openmp>/src/runtime/src/kmp.h:78, from <openmp>/src/runtime/src/kmp_environment.cpp:54: <openmp>/src/runtime/src/kmp_environment.cpp: In function ‘char* __kmp_env_get(const char*)’: <openmp>/src/runtime/src/kmp_safe_c_api.h:52:50: warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Wstringop-overflow=] #define KMP_STRNCPY_S(dst, bsz, src, cnt) strncpy(dst, src, cnt) ~~~~~~~^~~~~~~~~~~~~~~ <openmp>/src/runtime/src/kmp_environment.cpp:97:5: note: in expansion of macro ‘KMP_STRNCPY_S’ KMP_STRNCPY_S(result, len, value, len); ^~~~~~~~~~~~~ <openmp>/src/runtime/src/kmp_environment.cpp:92:28: note: length computed here size_t len = KMP_STRLEN(value) + 1; This is stupid because result is allocated with KMP_INTERNAL_MALLOC(len), so the arguments are correct. Differential Revision: https://reviews.llvm.org/D49904 llvm-svn: 338283
2018-07-30 10:16:22 -08:00
libomp_append(flags_local -Wstringop-overflow=0 LIBOMP_HAVE_WSTRINGOP_OVERFLOW_FLAG)
[OpenMP] Fix detecting warning options for GCC If testing for a warning option like -Wno-<foo> with GCC, GCC won't print any diagnostic at all, leading to the options being accepted incorrectly. However later, if compiling a file that actually prints another warning, GCC will also print warnings about these -Wno-<foo> options being unrecognized. This avoids warning spam like this, for every OpenMP source file that produces build warnings with GCC: cc1plus: warning: unrecognized command line option ‘-Wno-int-to-void-pointer-cast’ cc1plus: warning: unrecognized command line option ‘-Wno-return-type-c-linkage’ cc1plus: warning: unrecognized command line option ‘-Wno-covered-switch-default’ cc1plus: warning: unrecognized command line option ‘-Wno-enum-constexpr-conversion’ This matches how such warning options are detected and added in llvm/cmake/modules/HandleLLVMOptions.cmake, e.g. like this: check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG) append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS) This also matches how LLDB warning options were restructured for GCC compatibility in e546bbfda0ab91cf78c096d8c035851cc7c3b9f3. Differential Revision: https://reviews.llvm.org/D139922
2022-12-13 00:39:27 -09:00
libomp_append(flags_local -Wno-stringop-truncation LIBOMP_HAVE_WSTRINGOP_TRUNCATION_FLAG)
libomp_append(flags_local -Wno-switch LIBOMP_HAVE_WSWITCH_FLAG)
libomp_append(flags_local -Wno-uninitialized LIBOMP_HAVE_WUNINITIALIZED_FLAG)
libomp_append(flags_local -Wno-return-type-c-linkage LIBOMP_HAVE_WRETURN_TYPE_C_LINKAGE_FLAG)
libomp_append(flags_local -Wno-cast-qual LIBOMP_HAVE_WCAST_QUAL_FLAG)
libomp_append(flags_local -Wno-int-to-void-pointer-cast LIBOMP_HAVE_WINT_TO_VOID_POINTER_CAST_FLAG)
[OpenMP] libomp: Handle implicit conversion warnings This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions can possibly change a value. For builds done with icc or gcc, all such warnings are handled in this patch. clang gives a much longer list of warnings, particularly for sign conversions, which the other compilers don't report. The -Wconversion flag is commented into cmake files, but I'm not going to turn it on. If someone thinks it is important, and wants to fix all the clang warnings, they are welcome to. Types of changes made here involve either improving the consistency of types used so that no conversion is needed, or else performing careful explicit conversions, when we're sure a problem won't arise. Patch is a combination of changes by Terry Wilmarth and Johnny Peyton. Differential Revision: https://reviews.llvm.org/D92942
2020-12-30 12:39:48 -09:00
# libomp_append(flags_local -Wconversion LIBOMP_HAVE_WCONVERSION_FLAG)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(flags_local /GS LIBOMP_HAVE_GS_FLAG)
libomp_append(flags_local /EHsc LIBOMP_HAVE_EHSC_FLAG)
libomp_append(flags_local /Oy- LIBOMP_HAVE_OY__FLAG)
[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 03:21:36 -09:00
if(IA32 OR INTEL64)
[openmp] Only try to add the -mrtm flag on i386/x86_64 Clang does accept the flag for any architecture, but prints a warning: clang-16: warning: argument unused during compilation: '-mrtm' [-Wunused-command-line-argument] This flag is documented as an x86 specific flag, so don't try to add it for other architectures, to silence this warning. Differential Revision: https://reviews.llvm.org/D137744
2022-11-08 04:31:40 -09:00
libomp_append(flags_local -mrtm LIBOMP_HAVE_MRTM_FLAG)
endif()
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
# Intel(R) C Compiler flags
libomp_append(flags_local /Qsafeseh LIBOMP_HAVE_QSAFESEH_FLAG)
libomp_append(flags_local -Qoption,cpp,--extended_float_types LIBOMP_HAVE_EXTENDED_FLOAT_TYPES_FLAG)
libomp_append(flags_local -Qlong_double LIBOMP_HAVE_LONG_DOUBLE_FLAG)
libomp_append(flags_local -Qdiag-disable:177 LIBOMP_HAVE_DIAG_DISABLE_177_FLAG)
[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 03:21:36 -09:00
if(RELEASE_BUILD OR RELWITHDEBINFO_BUILD)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(flags_local -Qinline-min-size=1 LIBOMP_HAVE_INLINE_MIN_SIZE_FLAG)
endif()
# Architectural C and C++ flags
[OpenMP][cmake] Simplify -m32 handling (#142742) Linking `libomp.so` on 32-bit SPARC `FAIL`s with ``` ld: fatal: file projects/openmp/runtime/src/CMakeFiles/omp.dir/z_Linux_asm.S.o: wrong ELF class: ELFCLASS64 ``` This was a 1-stage build with a 64-bit-default `gcc`. Unlike the C++ sources, which were compiled as 32-bit objects due to the use of `-DCMAKE_CXX_FLAGS=-m32`, the assembler sources were not. This patch simplifies passing `-m32`: instead of doing it per architecture, `-m32` is now always passed when the target uses 32-bit pointers and supports the option. Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`, `sparc-unknown-linux-gnu`, `sparc64-unknown-linux-gnu`, `i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and `x86_64-pc-linux-gnu`.
2025-06-04 22:34:59 -08:00
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
libomp_append(flags_local -m32 LIBOMP_HAVE_M32_FLAG)
endif()
[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 03:21:36 -09:00
if(IA32)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(flags_local /arch:SSE2 LIBOMP_HAVE_ARCH_SSE2_FLAG)
libomp_append(flags_local -msse2 LIBOMP_HAVE_MSSE2_FLAG)
libomp_append(flags_local -falign-stack=maintain-16-byte LIBOMP_HAVE_FALIGN_STACK_FLAG)
[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 03:21:36 -09:00
elseif(MIC)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(flags_local -mmic LIBOMP_HAVE_MMIC_FLAG)
libomp_append(flags_local -ftls-model=initial-exec LIBOMP_HAVE_FTLS_MODEL_FLAG)
libomp_append(flags_local "-opt-streaming-stores never" LIBOMP_HAVE_OPT_STREAMING_STORES_FLAG)
endif()
[OpenMP] Turn on -Wall compiler warnings by default Instead, maintain a list of disabled options to still build libomp and libomptarget without warnings. This includes -Wno-error and -Wno-pedantic to silence warnings that LLVM enables when building in-tree. I tested the following compilers: * Clang 6.0, 7.0, 8.0 * GCC 4.8.5 (CentOS 7), GCC 6, 7, 8, 9 * Intel Compiler 16, 17, 18, 19 RFC thread on openmp-dev mailing list: http://lists.llvm.org/pipermail/openmp-dev/2019-August/002668.html Differential Revision: https://reviews.llvm.org/D65867 llvm-svn: 368999
2019-08-15 05:11:50 -08:00
set(cxxflags_local ${flags_local} ${LIBOMP_CXXFLAGS})
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_setup_flags(cxxflags_local)
set(${cxxflags} ${cxxflags_local} PARENT_SCOPE)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endfunction()
# Assembler flags
function(libomp_get_asmflags asmflags)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(asmflags_local)
# Architectural assembler flags
[OpenMP][cmake] Simplify -m32 handling (#142742) Linking `libomp.so` on 32-bit SPARC `FAIL`s with ``` ld: fatal: file projects/openmp/runtime/src/CMakeFiles/omp.dir/z_Linux_asm.S.o: wrong ELF class: ELFCLASS64 ``` This was a 1-stage build with a 64-bit-default `gcc`. Unlike the C++ sources, which were compiled as 32-bit objects due to the use of `-DCMAKE_CXX_FLAGS=-m32`, the assembler sources were not. This patch simplifies passing `-m32`: instead of doing it per architecture, `-m32` is now always passed when the target uses 32-bit pointers and supports the option. Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`, `sparc-unknown-linux-gnu`, `sparc64-unknown-linux-gnu`, `i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and `x86_64-pc-linux-gnu`.
2025-06-04 22:34:59 -08:00
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
libomp_append(asmflags_local -m32 LIBOMP_HAVE_M32_FLAG)
endif()
[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 03:21:36 -09:00
if(IA32)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(asmflags_local /safeseh LIBOMP_HAVE_SAFESEH_MASM_FLAG)
libomp_append(asmflags_local /coff LIBOMP_HAVE_COFF_MASM_FLAG)
[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 03:21:36 -09:00
elseif(MIC)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(asmflags_local -mmic LIBOMP_HAVE_MMIC_FLAG)
endif()
set(asmflags_local ${asmflags_local} ${LIBOMP_ASMFLAGS})
libomp_setup_flags(asmflags_local)
set(${asmflags} ${asmflags_local} PARENT_SCOPE)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endfunction()
# Linker flags
function(libomp_get_ldflags ldflags)
[OpenMP] Add libomp unit test infrastructure (#168063) (The tests in `TestKmpStr.cpp` are an automatically generated POC to make sure things work.)
2026-01-12 06:02:15 -09:00
cmake_parse_arguments(ARG "FOR_UNITTESTS" "" "" ${ARGN})
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(ldflags_local)
libomp_append(ldflags_local "${CMAKE_LINK_DEF_FILE_FLAG}${CMAKE_CURRENT_BINARY_DIR}/${LIBOMP_LIB_NAME}.def"
IF_DEFINED CMAKE_LINK_DEF_FILE_FLAG)
[OpenMP] [CMake] Removing expand-vars.pl in favor of CMake's configure_file() Currently, the libomp CMake build system uses a Perl script to configure files (tools/expand-vars.pl). This patch replaces the use of the Perl script by using CMake's configure_file() function. The major changes include: 1. *.var has every $KMP_* variable changed to @LIBOMP_*@ 2. kmp_config.h.cmake is a new file which contains all the feature macros and #cmakedefine lines 3. Most of the -D lines have been moved from LibompDefinitions.cmake but some OS specific MACROs (e.g., _GNU_SOURCE) remain. 4. All expand-vars.pl related logic is removed from the CMake files. One important note about this change is that it breaks the old Perl+Makefile build system because it can't create kmp_config.h properly. Differential Review: http://reviews.llvm.org/D12211 llvm-svn: 246314
2015-08-28 10:42:10 -08:00
libomp_append(ldflags_local "${CMAKE_C_OSX_CURRENT_VERSION_FLAG}${LIBOMP_VERSION_MAJOR}.${LIBOMP_VERSION_MINOR}"
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
IF_DEFINED CMAKE_C_OSX_CURRENT_VERSION_FLAG)
[OpenMP] [CMake] Removing expand-vars.pl in favor of CMake's configure_file() Currently, the libomp CMake build system uses a Perl script to configure files (tools/expand-vars.pl). This patch replaces the use of the Perl script by using CMake's configure_file() function. The major changes include: 1. *.var has every $KMP_* variable changed to @LIBOMP_*@ 2. kmp_config.h.cmake is a new file which contains all the feature macros and #cmakedefine lines 3. Most of the -D lines have been moved from LibompDefinitions.cmake but some OS specific MACROs (e.g., _GNU_SOURCE) remain. 4. All expand-vars.pl related logic is removed from the CMake files. One important note about this change is that it breaks the old Perl+Makefile build system because it can't create kmp_config.h properly. Differential Review: http://reviews.llvm.org/D12211 llvm-svn: 246314
2015-08-28 10:42:10 -08:00
libomp_append(ldflags_local "${CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG}${LIBOMP_VERSION_MAJOR}.${LIBOMP_VERSION_MINOR}"
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
IF_DEFINED CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG)
libomp_append(ldflags_local -Wl,--as-needed LIBOMP_HAVE_AS_NEEDED_FLAG)
[OpenMP] Add libomp unit test infrastructure (#168063) (The tests in `TestKmpStr.cpp` are an automatically generated POC to make sure things work.)
2026-01-12 06:02:15 -09:00
if(ARG_FOR_UNITTESTS)
libomp_append(ldflags_local "-Wl,--version-script=${LIBOMP_SRC_DIR}/exports_test_so.txt" LIBOMP_HAVE_VERSION_SCRIPT_FLAG)
else()
libomp_append(ldflags_local "-Wl,--version-script=${LIBOMP_SRC_DIR}/exports_so.txt" LIBOMP_HAVE_VERSION_SCRIPT_FLAG)
endif()
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(ldflags_local -static-libgcc LIBOMP_HAVE_STATIC_LIBGCC_FLAG)
libomp_append(ldflags_local -Wl,-z,noexecstack LIBOMP_HAVE_Z_NOEXECSTACK_FLAG)
libomp_append(ldflags_local -no-intel-extensions LIBOMP_HAVE_NO_INTEL_EXTENSIONS_FLAG)
libomp_append(ldflags_local -static-intel LIBOMP_HAVE_STATIC_INTEL_FLAG)
libomp_append(ldflags_local /SAFESEH LIBOMP_HAVE_SAFESEH_FLAG)
# Architectural linker flags
[OpenMP][cmake] Simplify -m32 handling (#142742) Linking `libomp.so` on 32-bit SPARC `FAIL`s with ``` ld: fatal: file projects/openmp/runtime/src/CMakeFiles/omp.dir/z_Linux_asm.S.o: wrong ELF class: ELFCLASS64 ``` This was a 1-stage build with a 64-bit-default `gcc`. Unlike the C++ sources, which were compiled as 32-bit objects due to the use of `-DCMAKE_CXX_FLAGS=-m32`, the assembler sources were not. This patch simplifies passing `-m32`: instead of doing it per architecture, `-m32` is now always passed when the target uses 32-bit pointers and supports the option. Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`, `sparc-unknown-linux-gnu`, `sparc64-unknown-linux-gnu`, `i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and `x86_64-pc-linux-gnu`.
2025-06-04 22:34:59 -08:00
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
libomp_append(ldflags_local -m32 LIBOMP_HAVE_M32_FLAG)
endif()
[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 03:21:36 -09:00
if(IA32)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(ldflags_local -msse2 LIBOMP_HAVE_MSSE2_FLAG)
[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 03:21:36 -09:00
elseif(MIC)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(ldflags_local -mmic LIBOMP_HAVE_MMIC_FLAG)
libomp_append(ldflags_local -Wl,-x LIBOMP_HAVE_X_FLAG)
endif()
set(ldflags_local ${ldflags_local} ${LIBOMP_LDFLAGS})
libomp_setup_flags(ldflags_local)
set(${ldflags} ${ldflags_local} PARENT_SCOPE)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endfunction()
# Library flags
function(libomp_get_libflags libflags)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(libflags_local)
libomp_append(libflags_local "${CMAKE_THREAD_LIBS_INIT}")
Adding Hwloc library option for affinity mechanism These changes allow libhwloc to be used as the topology discovery/affinity mechanism for libomp. It is supported on Unices. The code additions: * Canonicalize KMP_CPU_* interface macros so bitmask operations are implementation independent and work with both hwloc bitmaps and libomp bitmaps. So there are new KMP_CPU_ALLOC_* and KMP_CPU_ITERATE() macros and the like. These are all in kmp.h and appropriately placed. * Hwloc topology discovery code in kmp_affinity.cpp. This uses the hwloc interface to create a libomp address2os object which the rest of libomp knows how to handle already. * To build, use -DLIBOMP_USE_HWLOC=on and -DLIBOMP_HWLOC_INSTALL_DIR=/path/to/install/dir [default /usr/local]. If CMake can't find the library or hwloc.h, then it will tell you and exit. Differential Revision: http://reviews.llvm.org/D13991 llvm-svn: 254320
2015-11-30 11:02:59 -09:00
libomp_append(libflags_local "${LIBOMP_HWLOC_LIBRARY}" LIBOMP_USE_HWLOC)
[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 03:21:36 -09:00
if(IA32)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(libflags_local -lirc_pic LIBOMP_HAVE_IRC_PIC_LIBRARY)
endif()
[OpenMP] Enable omp_get_num_devices() on Windows This patch enables omp_get_num_devices() and omp_get_initial_device() on Windows by providing an alternative to dlsym on Windows, and proposes to add a new libomptarget entry, __tgt_get_num_devices(). Differential Revision: https://reviews.llvm.org/D96182
2021-02-05 05:53:40 -09:00
if(MINGW)
[OpenMP] Fix the check for libpsapi for i386 check_library_exists fails for stdcall functions, because that check doesn't include the necessary headers (and thus fails with an undefined reference to _EnumProcessModules, when the import library symbol actually is called _EnumProcessModules@16). Merge the two previous checks check_include_files and check_library_exists into one with check_c_source_compiles, and merge the variables that indicate whether it succeeded. Differential Revision: https://reviews.llvm.org/D96580
2021-02-12 00:20:10 -09:00
libomp_append(libflags_local -lpsapi LIBOMP_HAVE_PSAPI)
[OpenMP] Enable omp_get_num_devices() on Windows This patch enables omp_get_num_devices() and omp_get_initial_device() on Windows by providing an alternative to dlsym on Windows, and proposes to add a new libomptarget entry, __tgt_get_num_devices(). Differential Revision: https://reviews.llvm.org/D96182
2021-02-05 05:53:40 -09:00
endif()
[OpenMP] changing OMP rtl to use shared memory instead of env variable Patch by Erdner, Todd <todd.erdner@intel.com> Differential Revision: https://reviews.llvm.org/D89898
2020-10-26 08:02:21 -08:00
if(LIBOMP_HAVE_SHM_OPEN_WITH_LRT)
libomp_append(libflags_local -lrt)
endif()
[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537) A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20 08:45:41 -08:00
if("${CMAKE_SYSTEM_NAME}" MATCHES "DragonFly|FreeBSD|OpenBSD")
Add DragonFlyBSD support to OpenMP Summary: Additions mostly follow FreeBSD and NetBSD and are not intrusive. There is similar patch for OpenBSD: https://reviews.llvm.org/D34280 The -lm was being omitted due to -Wl,--as-needed in cmake rule, similar patch is in freebsd-ports/devel/llvm-devel port. Simple OpenMP programs compile and work as expected: $ clang-devel ~/omp_hello.c -fopenmp -I/usr/local/llvm-devel/include $ LD_LIBRARY_PATH=/usr/local/llvm-devel/lib OMP_NUM_THREADS=100 ./a.out The assertion in LLVMgold.so when -fopenmp was used together with -flto in 20170524 snapshot is no longer triggered on current svn-trunk and works fine as in llvm-4.0 with our local patches. Reviewers: #openmp, krytarowski Reviewed By: krytarowski Subscribers: dexonsmith, jfb, krytarowski, guansong, gregrodgers, emaste, mgorny, mehdi_amini Differential Revision: https://reviews.llvm.org/D35129 llvm-svn: 348725
2018-12-09 07:40:33 -09:00
libomp_append(libflags_local "-Wl,--no-as-needed" LIBOMP_HAVE_AS_NEEDED_FLAG)
libomp_append(libflags_local "-lm")
libomp_append(libflags_local "-Wl,--as-needed" LIBOMP_HAVE_AS_NEEDED_FLAG)
[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537) A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20 08:45:41 -08:00
if ("${CMAKE_SYSTEM_NAME}" STREQUAL "DragonFly")
[OpenMP] Implement __kmp_is_address_mapped on DragonFlyBSD. (#82895) implement internal __kmp_is_address_mapped.
2024-02-25 05:13:04 -09:00
libomp_append(libflags_local "-lkvm")
endif()
[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537) A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20 08:45:41 -08:00
elseif("${CMAKE_SYSTEM_NAME}" MATCHES "Linux|NetBSD|SunOS")
Complex division requires libm on NetBSD, add it. llvm-svn: 248207
2015-09-21 12:21:02 -08:00
libomp_append(libflags_local -lm)
Ensure correct pthread flags and libraries are used On most platforms, certain compiler and linker flags have to be passed when using pthreads, otherwise linking against libomp.so might fail with undefined references to several pthread functions. Use CMake's `find_package(Threads)` to determine these for standalone builds, or take them (and optionally modify them) from the top-level LLVM cmake files. Also, On FreeBSD, ensure that libomp.so is linked against libm.so, similar to NetBSD. Adjust test cases with hardcoded `-lpthread` flag to use the common build flags, which should now have the required pthread flags. Reviewers: emaste, jlpeyton, krytarowski, mgorny, protze.joachim, Hahnfeld Reviewed By: Hahnfeld Subscribers: AndreyChurbanov, tra, EricWF, Hahnfeld, jfb, jdoerfert, openmp-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D59451 llvm-svn: 357618
2019-04-03 10:11:36 -08:00
endif()
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(libflags_local ${libflags_local} ${LIBOMP_LIBFLAGS})
libomp_setup_flags(libflags_local)
[OpenMP][libomp] Make LIBOMP_CONFIGURED_LIBFLAGS a list instead of string When configuring llvm with the openmp subproject, the build for the omp target fails if LIBOMP_CONFIGURED_LIBFLAGS contains more than one item. LIBOMP_CONFIGURED_LIBFLAGS should be a semicolon-separated list instead of a string with items separated by spaces. Differential Revision: https://reviews.llvm.org/D125370
2022-06-02 07:45:02 -08:00
libomp_string_to_list("${libflags_local}" libflags_local_list)
set(${libflags} ${libflags_local_list} PARENT_SCOPE)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endfunction()
[OpenMP][libomp] Remove Perl in favor of Python (#95307) * Removes all Perl scripts and modules * Adds Python3 scripts which mimic the behavior of the Perl scripts * Removes Perl from CMake; Adds Python3 requirement to CMake * The check-instruction-set.pl script is Knights Corner specific. The script is removed and not replicated with a corresponding Python3 script. Relevant Discourse: https://discourse.llvm.org/t/error-compiling-clang-with-offloading-support/79223/4 Fixes: https://github.com/llvm/llvm-project/issues/62289
2024-06-20 09:54:49 -08:00
# Python generate-defs.py flags (For Windows only)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
function(libomp_get_gdflags gdflags)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(gdflags_local)
[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 03:21:36 -09:00
if(IA32)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(libomp_gdflag_arch arch_32)
Avoid exporting 80-bit fp functions for architectures other than Intel. This patch is a partial fix for [[ https://github.com/llvm/llvm-project/issues/56349 | issue ]], due to functions affected by D117473. Implementation details: The patch essentially creates a new macro if the architecture is either intel32 or intel64, since the generate-def.pl cannot process boolean algebra on macros. Reviewed By: jlpeyton Differential Revision: https://reviews.llvm.org/D135795
2022-10-19 06:55:15 -08:00
libomp_append(gdflags_local "-D IS_IA_ARCH")
[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 03:21:36 -09:00
elseif(INTEL64)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
set(libomp_gdflag_arch arch_32e)
Avoid exporting 80-bit fp functions for architectures other than Intel. This patch is a partial fix for [[ https://github.com/llvm/llvm-project/issues/56349 | issue ]], due to functions affected by D117473. Implementation details: The patch essentially creates a new macro if the architecture is either intel32 or intel64, since the generate-def.pl cannot process boolean algebra on macros. Reviewed By: jlpeyton Differential Revision: https://reviews.llvm.org/D135795
2022-10-19 06:55:15 -08:00
libomp_append(gdflags_local "-D IS_IA_ARCH")
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
else()
set(libomp_gdflag_arch arch_${LIBOMP_ARCH})
endif()
libomp_append(gdflags_local "-D ${libomp_gdflag_arch}")
libomp_append(gdflags_local "-D msvc_compat")
libomp_append(gdflags_local "-D norm" NORMAL_LIBRARY)
libomp_append(gdflags_local "-D prof" PROFILE_LIBRARY)
libomp_append(gdflags_local "-D stub" STUBS_LIBRARY)
libomp_append(gdflags_local "-D HAVE_QUAD" LIBOMP_USE_QUAD_PRECISION)
Fix link error on Windows when LIBOMP_USE_DEBUGGER is off Two symbols for the external debugger support were incorrectly exported when LIBOMP_USE_DEBUGGER=off. Differential Revision: http://reviews.llvm.org/D11763 llvm-svn: 244217
2015-08-06 07:16:54 -08:00
libomp_append(gdflags_local "-D USE_DEBUGGER" LIBOMP_USE_DEBUGGER)
[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 03:21:36 -09:00
if(DEBUG_BUILD OR RELWITHDEBINFO_BUILD)
Re-indent the CMake refactor to two-space indention I apologize for this nasty commit, but I somehow overlooked Chandler's comment to re-indent these files to two space indention. I know this is a horrible commit, but I figured if it was done quickly after the first one, not too many conflicts would arise. Again, I'm sorry and won't do this again. llvm-svn: 242301
2015-07-15 08:57:19 -08:00
libomp_append(gdflags_local "-D KMP_DEBUG")
endif()
set(${gdflags} ${gdflags_local} PARENT_SCOPE)
Large Refactor of CMake build system This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
2015-07-15 08:05:30 -08:00
endfunction()
Reference in a new issue Copy permalink