Since 23c665371a98c7a16765d12bf2db19b0626b7181 in llvm-project
(Nov 2, 2022), compiler-rt uses CMake's find_package() for
finding potentially installed LLVM files, instead of using
llvm-config.
If the surrounding distribution does have an unrelated install
of LLVM packages, compiler-rt's CMake files would find this, and
add include directories from it into the include paths used
when building compiler-rt.
The ORC runtimes include libc++ headers, and those error out
on these unexpected include topologies (when libc++'s cstddef
includes stddef.h and expects to get libc++'s stddef.h, but ends
up getting a different stddef.h included). (Without this,
it wouldn't have been noticed that the build ends up using a
mismatched sysroot's headers.)
This fixes building in msys2 in the clang64 environment, where
the base toolchain packages end up including LLVM packages,
including LLVMConfig.cmake.
This fixes the same issue as
3b96433cdf did, for the new form of
compiler-rt cmake files.
We used to copy libc++ and libunwind, since those were needed
to actually run the toolchain - but others, like the asan runtime,
may be needed for the user to be able to run the executables that
are built. If this bin directory is in the user's $PATH, they should
be picked up automatically.
For distribution, and for architectures other than the default,
the user still needs to use the binaries from the arch specific
directories.
This reverts commit 55db22d242.
The base tarball for setup-msys2 should now be new enough to
include the patched compiler in the clang64 environment, so this
no longer requires updating the environment on each build.
This was split in 591a5c2ddc since
we couldn't/shouldn't test these for UWP targets.
When the testing for UWP targets was reduced in
551b046498, there was no longer any
distinction between TESTS_CPP_LOAD_DLL and TESTS_CPP, so merge
them back.
As macOS itself doesn't ship with libzstd, avoid picking it up from
third party intallations.
CMake even looks for things in directories outside of $PATH;
for Darwin targets, CMake includes /opt/homebrew in
CMAKE_SYSTEM_PREFIX_PATH which gets searched automatically.
When some of the parameters to standard C functions are known
constants, the compiler can optimize out the call to the actual
function.
When built with fortification enabled, the compiler previously
didn't actually end up calling the __<func>_chk functions in
most cases, as it could optimize out much of the calls. Now all
tested function calls should end up emitted as intended, making
this actually do functional testing of the __<func>_chk function
implementations.
The literal NAN in MSVC is a negative NAN, while it is a positive one
in other environments. (strtod("NAN", NULL) did return a positive NAN
though.) In most tests where we test that NANs are preserved, the exact
sign doesn't matter much as long as it matches, but for some tests, it
does matter. Change to using variables with known representation
in the tests where it matters.
Also add a LL suffix to make a tricky constant more correct.
In MSVC, the variable initialization
long long i = -2147483648;
actually sets the variable to the positive value 2147483648 (both
in MSVC 2019 and 2022).
The macros F() and L() etc were meant for providing constants for
the tests, without the compiler seeing them as constants, to
avoid optimizing out the entire functions that are to be tested.
However in practice, the compiler is also able to optimize out
e.g. a call to strtol("42", NULL, 0), so this didn't have the
intended effect.
Instead make the macros wrap through a no-op function, but which
is indirected via a global function pointer. The compiler can't
reason about global variables keeping their values (they could be
modified by e.g. a constructor in a different object file, before
running the main function). This avoids needing to pass all values
through strtod/strtol etc.
Change some constants like 123456789012345, which are seen by
the compiler as integer constants (which aren't exactly representable
in floating point form) into 123456789012345.0, which the compiler
won't complain about being inexact.
Using two dashes for this option name is more idiomatic for
long GNU options (using only one dash only is supported for options
where it doesn't conflict with single-character options; it does
work for "-pdb" but "--pdb" is more correct).
Stop documenting the separate argument form "-Wl,--pdb,<filename>".
If noone would use this form, one could consider switching the tools
over to interpret "-Wl,--pdb" as a boolean option (optional_argument
instead of required_argument in getopt_long) as a less awkward syntax
for "-Wl,--pdb=".
PDB output now does work for armv7 (earlier it used to error out),
and the PDB output does work properly on aarch64.
(The recently added tests in run-lldb-tests.sh passes successfully on
aarch64. Debugging on armv7 with LLDB has got a few known issues though,
both with DWARF and with PDB, while WinDbg and/or Visual Studio might
work better.)
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
This is necessary for CMake to detect working IPO (LTO); if the
compiler is named <target>-{gcc,clang}, CMake expects to find
matching tools named <target>-llvm-{ar,ranlib} too. (The CMake
module CheckIPOSupported and function check_ipo_supported expects
to have CMAKE_LANG_COMPILER_AR and ..._RANLIB set to working tools;
the Clang-FindBinUtils.cmake module looks for tools named
llvm-ar/llvm-ranlib with the same prefix as the compiler.)
Normally, we'd split the string at the last dash. However if the
tool name is "llvm-<tool>", make sure to include "llvm-" in the
tool name part when splitting the executable name.
In llvm-wrapper, don't add a duplicate "llvm-" prefix for the tool
name in these cases.
This matches how the compiler driver normally includes default
linked libraries; the user provided -l flags are passed first,
followed by the compiler's default ones. That allows a user
specified library to override the default ones.
This makes sure that if a user provides -lwindowsappcompat, it
gets linked before -lwindowsapp, which makes a difference for
symbols that are provided in both (such as e.g. LoadLibraryW).
Run this for both i686 and x86_64, as we only test lldb with the
native architecture of the lldb executable (which is assumed to
be the same as the default architecture of the clang executable).
If the low byte of the stack cookie happens to be zero, we
previously wouldn't trigger any error.
This avoids accidentally failing to trigger the stack protector
once per 256 runs, roughly.
Martin Storsjö