By building the assembly with language ASM now (since
4072c8aee4c89c4457f4f30d01dc9bb4dfa52559 and
cbaa3597aaf6273e66b3f445ed36a6458143fe6a), this shouldn't be
needed any longer.
Differential Revision: https://reviews.llvm.org/D150701
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
Summary:
Building with `lld` now errors on undefined symbols by default now. This
was causing `libomp` to think that the compiler didn't support version
scripts when checking linker features. This patch adds a new script that
exports all symbols to be used for testing. We also remove the old
workarounds for undefined versions now that it's no longer necessary.
This option is legacy and is removed from GNU ld's doc (many binutils
distributions are configured with --enable-textrel-check=). lld ignores the
option.
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
Issue #58858: when linking libomp.so, exports_so.txt has non-existent/undefined
symbols which cause errors to ld --no-undefined-version. Use
-Wl,--undefined-version if available (gold, ld.lld, future GNU ld 2.40).
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
This reverts commit 096f93e73dc3f88636cdcb57515e3732385b452d.
Revert "[Libomptarget] Make the plugins ingore undefined exported symbols"
This reverts commit 3f62314c235bd2475c8e2b5b874b2932a444e823.
Revert "[LLD] Enable --no-undefined-version by default."
This reverts commit 7ec8b0d162e354c703f5390784287054601f9c69.
Three commits are reverted because of the current omp build fail
with GNU ld. See discussion here: https://reviews.llvm.org/rG096f93e73dc3
Summary:
A recent patch made all of the places we used version scripts in OpenMP
start throwing errors when linking with LLD. This is hopefully the last
one required to get the build bots to pass. This patch simply adds the
`--undefined-version` flag to the places where the version scripts are
used.
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
Several variables were left unused as a result of different patches removing
their use.
Two variables have some use:
`poll_count` is used by the KMP_BLOCKING macro only under certain conditions.
Adding (void) to tell the compiler to ignore the unused variable.
`padding` is a dummy stack allocation with no intent to be used. Also adding
(void) to make the compiler ignore the unused variable.
Differential Revision: https://reviews.llvm.org/D104303
This silences warnings like these, in mingw builds with clang:
runtime/src/kmp_atomic.h:1021:13: warning: '__kmpc_atomic_cmplx8_rd' has C-linkage specified, but returns user-defined type 'kmp_cmplx64' (aka '__kmp_cmplx64_t') which is incompatible with C [-Wreturn-type-c-linkage]
runtime/src/z_Windows_NT_util.cpp:479:17: warning: cast from 'volatile void *' to 'type-parameter-0-0 *' drops volatile qualifier [-Wcast-qual]
flag = (C *)th->th.th_sleep_loc;
runtime/src/z_Windows_NT_util.cpp:1321:14: warning: cast to 'void *' from smaller integer type 'DWORD' (aka 'unsigned long') [-Wint-to-void-pointer-cast]
} else if ((void *)exit_val != (void *)th) {
Differential Revision: https://reviews.llvm.org/D96585
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
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
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
Summary:
The termination function duplicated the functionality of the
__attribute((destructor))-annotated function __kmp_internal_end_fini,
and we have no indication that this doesn't work.
The function might cause issues with link-time optimization turned on:
until very recently, none of the usual linkers was reporting functions
named in -Wl,-fini as used to the LTO plugin, so it might be dropped.
If the function is dropped, -Wl,-fini=__kmp_internal_end_fini doesn't
do what we want: with ld.bfd and lld it drops the FINI attribute from
.dynamic and with gold we get FINI = 0x0, which leads to a crash on
cleanup. This can be reproduced by building with
-DLLVM_ENABLE_PROJECTS="clang;openmp" \
-DLLVM_ENABLE_LTO=Thin \
-DLLVM_USE_LINKER=gold
The issue in lld has been fixed in f95273f75aa, but gold remains without
fix so far.
Fixes PR43927.
Reviewers: JonChesterfield, jdoerfert, AndreyChurbanov
Reviewed By: AndreyChurbanov
Differential Revision: https://reviews.llvm.org/D69927
There's no need to initialize variables with static storage duration
because they're implicitly initialized to zero. See
https://en.cppreference.com/w/c/language/initialization#Implicit_initialization
I think that's already relied upon because the supplied 0 only sets
'kmp_time_global_t g_time;' in 'struct kmp_base_global'. The other fields
are not set in the code, but implicitly initialized by the compiler.
Differential Revision: https://reviews.llvm.org/D66292
llvm-svn: 370943
Fix last warned location in ittnotify_static.cpp using the defined
macro KMP_FALLTHROUGH().
Differential Revision: https://reviews.llvm.org/D65871
llvm-svn: 369003
The variables in kmp_lock.cpp are really arrays of function pointers
that return void or int, not pointers to functions that return void*
or int*. The other changes are only cosmetic.
Differential Revision: https://reviews.llvm.org/D65870
llvm-svn: 369002
The implementation status can only be one of
ompt_event_UNIMPLEMENTED = ompt_set_never = 1
ompt_event_MAY_ALWAYS = ompt_set_always = 5
In both cases, the condition was already true, so just remove
the check.
Differential Revision: https://reviews.llvm.org/D65869
llvm-svn: 369001
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
All other files are already C++ and the build system has always
passed '-x c++' for C files, effectively compiling them as C++.
To stay warning free we need one fix in ittnotify_static.{c,cpp}:
The variable dll_path can be written to, so it must not be const.
GCC complained with -Wcast-qual and I think it's right.
Differential Revision: https://reviews.llvm.org/D65285
llvm-svn: 367343
Remove all older OMP spec versioning from the runtime and build system.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D64534
llvm-svn: 365963
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
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
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
This patch cleans up unused functions, variables, sign compare issues, and
addresses some -Warning flags which are now enabled including -Wcast-qual.
Not all the warning flags in LibompHandleFlags.cmake are enabled, but some
are with this patch.
Some __kmp_gtid_from_* macros in kmp.h are switched to static inline functions
which allows us to remove the awkward definition of KMP_DEBUG_ASSERT() and
KMP_ASSERT() macros which used the comma operator. This had to be done for the
innumerable -Wunused-value warnings related to KMP_DEBUG_ASSERT()
Differential Revision: https://reviews.llvm.org/D49105
llvm-svn: 339393
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
These are needed by both libraries, so we can do that in a
common namespace and unify configuration parameters.
Also make sure that the user isn't requesting libomptarget
if the library cannot be built on the system. Issue an error
in that case.
Differential Revision: https://reviews.llvm.org/D40081
llvm-svn: 319342
Add build option LIBOMP_OMP_VERSION=50, 5.0 headers, and add the year/month
associated with OpenMP 5.0 in relevant source locations. Also, remove the
deprecated LIBOMP_OMP_VERSION=41 option.
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D30450
llvm-svn: 297083
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
OpenMP 4.1 is now OpenMP 4.5. Any mention of 41 or 4.1 is replaced with
45 or 4.5. Also, if the CMake option LIBOMP_OMP_VERSION is 41, CMake warns that
41 is deprecated and to use 45 instead.
llvm-svn: 272687
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
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
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
clean up the build.
This disables all of the Clang warnings that fire for me when building
libomp.so on Linux with a recent Clang binary. Lots of these should
probably be fixed, but I want to at least get the build warning-clean
and make it easy to keep that way.
I also switched a bunch of the warnings that are used both for C and C++
compiles to check the flag with C compilation test.
Differential Revision: http://reviews.llvm.org/D11253
llvm-svn: 242604
