Premerge CI is currently failing with the following after the update to
clang v22:
```
/home/gha/llvm-project/clang-tools-extra/clangd/benchmarks/IndexBenchmark.cpp:92:1: error: '__COUNTER__' is a C2y extension [-Werror,-Wc2y-extensions]
92 | BENCHMARK(dexQueries);
| ^
```
Some original work was done around this in
df1d786c460e0e47c9074f3533f098190ebfbc1b, which was then done in
upstream Google benchmark in
d8db2f90b6.
The original work done in the patch implementing this feature doesn't
seem to account for as many cases as the upstream patch does. This patch
reverts the diff in df1d786c460e0e47c9074f3533f098190ebfbc1b and applies
the applicable hunks from the upstream patch.
cc_binary now needs to be loaded from the rules_cc repo
I don't think this file is actually used, but updating it to be more
syntactically correct anyway.
The LLVM-customized GTest has a dependency on LLVM to support
`llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes
use the LLVMSupport from the bootstrapping LLVM build. The problem is
that the boostrapping compiler and the runtimes target can diverge in
their ABI, even in the runtimes default build. For instance, Clang is
built using gcc which uses libstdc++, but the runtimes is built by Clang
which can be configured to use libcxx by default. Altough it does not
use gcc, this issue has caused
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to
break, and is still (again?) broken.
This patch makes the runtimes' GTest independent from LLVMSupport so we
do not link any runtimes component with LLVM components.
Runtime projects that use GTest unittests:
* flang-rt
* libc
* compiler-rt: Adds `gtest-all.cpp` with
[GTEST_NO_LLVM_SUPPORT=1](f801b6f67e/compiler-rt/CMakeLists.txt (L723))
to each unittest without using `llvm_gtest`. Not touched by this PR.
* openmp: Handled by #159416. Not touched for now by this PR to avoid
conflict.
The current state of this PR tries to reuse
https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt
as much as possible, altough personally I would prefer to make it use
"modern CMake" style. third-party/unittest/CMakeLists.txt will detect
whether it is used in runtimes build and adjaust accordingly. It creates
a different target for LLVM (`llvm_gtest`, NFCI) and another one for the
runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest`
for both since `llvm_gtest` is imported using `find_package(LLVM)` if
configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to
select between the two. `default_gtest` could also be used for openmp
which also supports standalone and
[LLVM_ENABLE_PROJECTS](https://github.com/llvm/llvm-project/pull/152189)
build mode.
This implements the parts of
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3457.htm which were
adopted at the recent meeting in Brno.
Clang already implemented `__COUNTER__`, but needed some changes for
conformance. Specifically, we now diagnose when the macro is expanded
more than 2147483647 times. Additionally, we now give the expected
extension and pre-compat warnings for the feature.
To support testing the limits, this also adds a -cc1-only option,
`-finitial-counter-value=`, which lets you specify the initial value the
`__COUNTER__` macro should expand to.
This PR adds the code of Boost.Math as of version 1.89 into the
third-party directory, as discussed in a recent RFC [1].
The goal is for this code to be used as a back-end for the C++17
Math Special Functions.
As explained in third-paty/README.md, this code is cleared for
usage inside libc++ for the Math Special functions, however
the LLVM Foundation should be consulted before using this
code anywhere else in the LLVM project, due to the fact
that it is under the Boost Software License (as opposed
to the usual LLVM license). See the RFC [1] for more details.
[1]: https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on-boost-math-for-the-c-17-math-special-functions
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
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.
These changes allow LLVM and Clang to be built with Clang targeting
Arm64EC using the MSVC linker.
Built with these options:
```
-DLLVM_ENABLE_PROJECTS="clang"
-DLLVM_HOST_TRIPLE=arm64ec-pc-windows-msvc
-DCMAKE_C_COMPILER=clang-cl.exe
-DCMAKE_C_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_CXX_COMPILER=clang-cl.exe
-DCMAKE_CXX_COMPILER_TARGET=arm64ec-pc-windows-msvc
-DCMAKE_LINKER_TYPE=MSVC
```
#147357 attempted to fix an MSVC in sysinfo.cc by adding a `case` block
for a missing enum value.
However, this resulted in [CI
failures](https://github.com/llvm/llvm-project/pull/147357#issuecomment-3079709852):
```
4.170 [148/4/9] Building CXX object third-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj
FAILED: third-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj
C:\Users\tcwg\scoop\shims\ccache.exe C:\Users\tcwg\scoop\apps\llvm-arm64\current\bin\clang-cl.exe /nologo -TP -DBENCHMARK_STATIC_DEFINE -DEXPERIMENTAL_KEY_INSTRUCTIONS -DHAVE_STD_REGEX -DHAVE_STEADY_CLOCK -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/third-party/benchmark/src -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/llvm/include -IC:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/include /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- -Werror=unguarded-availability-new -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported /Gw /W4 -EHs- -EHa- /O2 /Ob2 -std:c++14 -MD -UNDEBUG /showIncludes /Fothird-party/benchmark/src/CMakeFiles/benchmark.dir/sysinfo.cc.obj /Fdthird-party\benchmark\src\CMakeFiles\benchmark.dir\benchmark.pdb -c -- C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src/sysinfo.cc
C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/third-party/benchmark/src/sysinfo.cc(374,12): error: use of undeclared identifier 'CacheUnknown'
374 | case CacheUnknown:
| ^
1 error generated.
```
The root cause is that the enum being switched on is defined in the
Windows SDK, so depending on which version of the SDK you are using
`CacheUnknown` may or may not be defined.
The correct fix here is to use a `default` block in the switch statement
instead.
Building LLVM with MSVC is raising the following warning:
```
llvm\third-party\benchmark\src\sysinfo.cc(375): warning C4062: enumerator 'CacheUnknown' in switch of enum '_PROCESSOR_CACHE_TYPE' is not handled
```
This change resolves the warning by moving the `Unknown` type into a
case block for `CacheUnknown`.
Not sure how this code flows back into the original source.
Add the top-level LLVM include directory to the `llvm_gtest` target, as
it requires `llvm/Support/raw_os_ostream.h` header. This fixes a
flang-rt unittest build failure introduced in #143682.
The original commit removed them to avoid the dependency on llvm Support
because of LLVM_FALLTHROUGH, but this triggers `-Wimplicit-fallthrough`
warnings.
LLVM requires a C++17 compiler now, so we should be able to use the
standard [[fallthrough]] attribute.
This is so that we'll be able to use it in compiler-rt as well.
Dependencies on LLVM Support were removed from the header by restoring
code from the original SipHash implementation.
Reviewers: kuhar, dwblaikie, ahmedbougacha
Reviewed By: dwblaikie
Pull Request: https://github.com/llvm/llvm-project/pull/134197
The Offload and Flang-RT had the ability to compile GTest themselves.
But in bootstrapping builds, LLVM_LIBRARY_OUTPUT_INTDIR points to the
same location as the stage1 build. If both are building GTest, they
everwrite each others `libllvm_gtest.a` and `libllvm_test_main.a` which
causes #143134.
This PR removes the ability for the Offload/Flang-RT runtimes to build
their own GTest and instead relies on the stage1 build of GTest. This
was already the case with LLVM_INSTALL_GTEST=ON configurations. For
LLVM_INSTALL_GTEST=OFF configurations, we now also export gtest into the
buildtree configuration. Ultimately, this reduces combinatorial
explosion of configurations in which unittests could be built
(LLVM_INSTALL_GTEST=ON, GTest built by Offload, GTest built by Flang-RT,
GTest built by Offload and also used by Flang-RT).
GTest and therefore Offload/Runtime unittests will not be available if
the runtimes are configured against an LLVM install tree. Since llvm-lit
isn't available in the install tree either, it doesn't matter.
Note that compiler-rt and libc also use GTest in non-default
configrations. libc also depends on LLVM's GTest build (and would
error-out if unavailable), but compiler-rt builds it completely
different.
Fixes#143134
Silence a warning in gtest casting a char8_t/char16_t to char32_t.
Note that this cast, as well as the behavior of `PrintTo(char32_t)` is
incorrect when printing a code unit that does not represent a code
point. See https://github.com/google/googletest/issues/4762
Try to use the _SC_NPROCESSORS_ONLN sysconf elsewhere
(cherry picked from commit edb1e76d8cb080a396c7c992e5d4023e1a777bd1)
Replace usage of deprecated sysctl on macOS
(cherry picked from commit faaa266d33ff203e28b31dd31be9f90c29f28d04)
Retrieve the number of online CPUs on OpenBSD and NetBSD
(cherry picked from commit 41e81b1ca4bbb41d234f2d0f2c56591db78ebb83)
Update error message now that /proc/cpuinfo is no longer in use
(cherry picked from commit c35af58b61daa111c93924e0e7b65022871fadac)
Fix runtime crash when parsing /proc/cpuinfo fails
(cherry picked from commit 39be87d3004ff9ff4cdf736651af80c3d15e2497)
another reversal of something that breaks on wasm
(cherry picked from commit 44507bc91ff9a23ad8ad4120cfc6b0d9bd27e2ca)
As like 48d868493fa74025e7768afacdbbbd3ea9c82468, `WORKSPACE` is another
bazel-specific file that is unused. LLVM's bazel configuration is
entirely in `utils/bazel`.
This reverts commit aec6a04b8e99b42eca431fc0b56947937d3a14c2.
(google/benchmark still at hash 1576991177ba97a4b2ff6c45950f1fa6e9aa678c as it was in #83488. Also reapplied same extra local diffs)
Verified locally.
This patch calls ProcessCPUUsage() for z/OS because we do not support CLOCK_THREAD_CPUTIME_ID. This copies the change made to google benchmark here
e3824e7503
The new implementation was brought in with the gtest update in
a866ce789eb99da4d7a486eeb60a53be6c75f4fd, but it crashes when
building with rpmalloc, see
https://github.com/llvm/llvm-project/pull/65823#issuecomment-1739820534
Comment out the new implementation basically gives us the code
before the gtest update.
This patch reland 54c1a9b20d89e85cd60d002c77b34c00f36520f4, which
updates GoogleTest to v1.14.0. This patch fixes bots failures caused
by the early patch.
D158607 switched this code to use CMAKE_INSTALL_LIBDIR, but kept
the explicit LLVM_DIR_SUFFIX. However, CMAKE_INSTALL_LIBDIR already
contains the suffix, so we end up installing into a path like
lib6464.
When an assertion like the following fails:
EXPECT_THAT(map, ElementsAre(Pair("p", "nullable"))));
Error message before:
Actual: { 40-byte object <E8-A5 9C-7F 25-37 00-00 58-7E 51-51 D0-7F 00-00 00-00 00-00 00-00 00-00 01-00 00-00 00-00 00-00 00-DA C7-7F 25-37 00-00> }
After:
Actual: { ("p", "nonnull") }
It is not ideal that we need to refer directly to DenseMapPair inside the
internal namespace, but I believe the practical maintenance risk is low.
This change is covered by DenseMap's unittests, as we've covered SmallString etc
in the past.
Differential Revision: https://reviews.llvm.org/D153930
This reverts commit dfbcee286b9b96751014ebc5ba5290e42796be37.
This was causing unit tests to fail on Gentoo, see comments on
https://reviews.llvm.org/D152696.
We have recently started seeing deadlocks in death tests while running in an internal test environment.
Per the documentation here, there are issues with death tests in the presence of threads:
https://github.com/google/googletest/blob/main/docs/advanced.md#death-tests-and-threads
To avoid the deadlocks, I first tried appending `DeathTest` to the relevant test suite names, which has the effect of running these test suites before all other tests. However, this did not prevent the deadlocks.
This patch therefore uses the option of setting the `death_test_style` flag to `"threadsafe"` (see description in the page linked above under "Death Test Styles"), and this prevents the deadlocks.
The documentation notes that the "threadsafe" death test style "trades increased test execution time (potentially dramatically so) for improved thread safety". This is because, to execute a death test, "threadsafe" does a "fork + exec", then re-executes the current test in the child process, whereas the default "fast" death test style does only a fork (on those platforms that support it). However, as we have relatively few death tests, the increased execution time does not make a big difference in total test execution time in my testing.
Note that other projects, such as Chromium, also choose to set the "threadsafe" death test style globally:
https://source.chromium.org/chromium/chromium/src/+/main:base/test/test_suite.cc;l=367
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D152696
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
Pass BUILDTREE_ONLY to llvm_gtest_main only if LLVM_INSTALL_GTEST
is not set. This fixes 0807986303f5d498cee32d42c242940d00617ad9.
Otherwise, llvm_gtest_main cannot be used
in LLVM_DISTRIBUTION_COMPONENTS, effectively making it impossible
to install llvm_gtest correctly.
Differential Revision: https://reviews.llvm.org/D145946
Stand-alone builds need an installed version of gtest in order to run
the unittests.
Reviewed By: mgorny, kwk
Differential Revision: https://reviews.llvm.org/D137890
Exclude building googletest and LLVMTestingSupport libraries from
the `all` target. If unittests are being built, these libraries will
be built as a dependency anyway. If they are not being built, building
them makes little sense as they are not installed or used otherwise.
This will also make standalone builds of other projects easier, as it
makes it possible to include these directories without having to cover
them with additional conditions to prevent them from being built
unconditionally.
Differential Revision: https://reviews.llvm.org/D137035
This reverts commit 59052468c3e38cab15582cefbb5133fd4c2ffce5.
It looks like this patch breaks the build when compiler-rt is passed to
LLVM_ENABLE_PROJECTS instead of LLVM_ENABLE_RUNTIMES.
This will help improve the project's layering, so that sub-projects
that don't actually need any llvm code can still use googletest
without having to reference code in the llvm directory.
This will also make it easier to consolidate and simplify the standalone
build configurations.
Reviewed By: stellaraccident, lattner, probinson, phosek
Differential Revision: https://reviews.llvm.org/D131919
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
