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.
Although the false positives that caused it to be disabled originally
may have been fixed in GCC 12, GCC also suffers from a problem where
-Wuninitialized may cause the build to hang on some platforms (GCC
#120729). This has been fixed in GCC 15, so turn on -Wuninitialized for
GCC 15+ instead of GCC 12+.
On unix systems, we were trying to determine the terminal width using
the `COULMNS` environment variable. Unfortunately, `COLUMNS` is not
exported by all shells and thus not available on some systems.
We were previously using `ioctl()` for this; fall back to doing so if `COLUMNS`
does not exist or does not store a positive integer.
This essentially reverts a3eb3d3d92d037fe3c9deaad87f6fc42fe9ea766 and
parts of https://reviews.llvm.org/D61326.
For more information, see #139499.
Fixes#139499.
Prefers the page size to come from the AUX vector, `getpagesize` is
removed from POSIX.1-2001. Also throws in a couple asserts to ensure the
page size is a valid value.
On systems with glibc, clock_gettime() was moved from librt to libc in
version 2.17, in which case the current librt detection attempt would
always fail.
Look for shm_open instead, like other parts of the tree also do when
looking for librt.
Co-authored-by: Raphael Kubo da Costa <kubo@igalia.com>
This patch removes 11 `check_include_file` invocations from
configuration phase of LLVM subproject on most of the platforms,
hardcoding the results. Fallback is left for platforms that we don't
document as supported or that are not detectable via
`CMAKE_SYSTEM_NAME`, e.g. z/OS.
This patch reduces configuration time on Linux by 10%, going from 44.7
seconds down to 40.6 seconds on my Debian machine (ramdisk, `cmake
-DLLVM_ENABLE_PROJECTS="clang;lldb;clang-tools-extra"
-DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi"
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_OPTIMIZED_TABLEGEN=ON
-DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_ENABLE_DOXYGEN=ON
-DLLVM_ENABLE_LIBCXX=ON -DBUILD_SHARED_LIBS=ON -DLLDB_ENABLE_PYTHON=ON
~/endill/llvm-project/llvm`).
In order to determine the values to hardcode, I prepared the following
header:
```cpp
#include <dlfcn.h>
#include <errno.h>
#include <fcntl.h>
#include <fenv.h>
#include <mach/mach.h>
#include <malloc/malloc.h>
#include <pthread.h>
#include <signal.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/param.h>
#include <sys/resource.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sysexits.h>
#include <termios.h>
#include <unistd.h>
int main() {}
```
and tried to compile it on the oldest versions of platforms that are
still supported (which was problematic to determine sometimes): macOS
12, Cygwin, DragonFly BSD 6.4.0, FreeBSD 13.3, Haiku R1 beta 4, RHEL
8.10 as a glibc-based Linux, Alpine 3.17 as musl-based Linux, NetBSD 9,
OpenBSD 7.4, Solaris 11.4, Windows SDK 10.0.17763.0, which corresponds
to Windows 10 1809 and is the oldest Windows 10 SDK in Visual Studio
Installer.
For platforms I don't have access to, which are AIX 7.2 TL5 and z/OS
2.4.0, I had to rely on the official documentation. I suspect that AIX
offers a better set of headers than what this PR claims, so I'm open to
input from people who have access to a live system to test it.
Similarly to AIX, I have values for z/OS compiled from the official
documentation that are not included in this patch, because apparently
upstream CMake doesn't even support z/OS, so I don't even know how to
make a place to hold those values. I see `if (ZOS)` in several places
across our CMake files, but it's a mystery to me where this variable
comes from. Input from people who have access to live z/OS instance is
welcome.
These are unneeded even on AIX, PURE_WINDOWS, and ZOS (per #104706)
* HAVE_ERRNO_H: introduced by 1a93330ffa2ae2aa0b49461f05e6f0d51e8443f8 (2009) but unneeded.
The guarded ABI is unconditionally used by lldb.
* HAVE_FCNTL_H
* HAVE_FENV_H
* HAVE_SYS_STAT_H
Pull Request: https://github.com/llvm/llvm-project/pull/123087
When compiling LLVM with -std=c++ instead of -std=gnu we'd fail to detect many newer POSIX functions.
We define it for the whole of LLVM anyway so moving the definition to the top fixes detection of a bunch of these on such setups.
Keeping it at the top also avoids accidentally introducing new dependent checks before it being defined.
ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`.
LLVM should not change the behavior depending on host configurations.
This reverts commit 14c7e4a1844904f3db9b2dc93b722925a8c66b27.
(llvmorg-20-init-3262-g14c7e4a18449 and llvmorg-20-init-3498-g001e423ac626)
The intent is that the tests should not be running on PowerPC as the fp128 type
will differ. This attempts to fix the bots by using __powerpc__ instead, which
appears to be defined in godbolt.
This is a reland of (#96287). This patch attempts to reduce the reverted
patch's clang compile time by removing #includes of float128.h and
inlining convertToQuad functions instead.
This is a reland of #96287. This change makes tests in logf128.ll ignore
the sign of NaNs for negative value tests and moves an #include <cmath>
to be blocked behind #ifndef _GLIBCXX_MATH_H.
This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is
available and checking if the host does not use __ibm128 which is
prevalent on power pc targets and replaces IEEE754 float128s.
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is available
and checking if the host does not use __ibm128 which is prevalent on power pc
targets and replaces IEEE754 float128s.
This patch enables constant folding for 128 bit floating-point logf
calls. This is achieved by querying if the host system has the logf128()
symbol available with a CMake test. If so, replace the runtime call with
the compile time value returned from logf128.
In newer SDKs, ld64 is called ld-classic. Look for it first, as ld in
those SDKs is still missing some functionality some tests depend on.
This enables running the tests from check-llvm-tools-lto with newer SDKs
on ARM64 macOS.
With LTO, gcc's IPA passes might drop the foo() function and then the test
will pass even on platforms where __builtin_thread_pointer is unavailable.
On PPC64, we get this as a result:
```
llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:361:61: error: ‘__builtin_thread_pointer’ is not supported on this targ
```
Just mark the function in the CMake configure test with the 'used' attribute to
avoid it being optimised out. The test then behaves correctly with -flto.
Tested with e.g. 'powerpc64le-linux-gnu-gcc -O2 -flto a.c'.
Reported-by: matoro
Reviewed-by: maskray
Closes: https://github.com/llvm/llvm-project/pull/70968
Signed-off-by: Sam James <sam@gentoo.org>
It's no longer possible to submit bitcode apps to the Apple App Store.
The tools
used to create xar archived bitcode sections inside MachO files have
been
discontinued. Additionally, the xar APIs have been deprecated since
macOS 12,
so this change removes unnecessary code from objdump and all
dependencies on
libxar.
This fixes rdar://116600767
Due to arguably a bug in GCC[0], using `__has_builtin` is not sufficient to check whether `__builtin_thread_pointer` can actually be compiled by GCC. This makes it impossible to compile LLVM with `llvm-exegesis` enabled with e.g. GCC 10 as it does have the builtin, but no implementation for architectures such as x86.
This patch works around this issue by making it a cmake configure check whether the builtin can be compiled and used, rather than relying on the broken preprocessor macro.
[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952, demonstration: https://godbolt.org/z/9z5nWM6Ef
Differential Revision: https://reviews.llvm.org/D155828
After building and installing LLVM with LibEdit as a dependency, it is
necessary to find it again when LLVM is consumed by another CMake
project, otherwise CMake will report an error about a missing target.
Note that the FindLibEdit.cmake file is in the "LLVM Common CMake
Utils" directory, outside of the LLVM sub-project source directory, so
the installed LLVMConfig.cmake relies on the user having installed the
LLVM common CMake modules or make available their own Find module.
Also note that the controlling HAVE_LIBEDIT CMake variable in
LLVMConfig.cmake.in has a different naming convention compared to
other similar variables like 'LLVM_ENABLE_TERMINFO'. Refactoring this
name would involve touching additional files and should be a follow-up
commit.
Patch By: ekilmer
Differential Revision: https://reviews.llvm.org/D147153
Since GetErrcMessages uses cmake's `try_run` mechanism it's sensitive
to changes to CMAKE_CXX_FLAGS, so we move it into config-ix with the
similar flag-sensitive configuration. This makes it run before
HandleLLVMOptions and avoids issues with LLVM_ENABLE_WERROR and other
configuration that manipulate CMAKE_CXX_FLAGS.
Differential Revision: https://reviews.llvm.org/D144526
Pass -D_FILE_OFFSET_BITS=64 to compiler flags on 32bit glibc based
systems. This will make sure that 64bit versions of LFS functions are
used e.g. seek will behave same as lseek64. Also revert [1] partially
because this added a cmake test to detect lseek64 but then forgot to
pass the needed macro to actual compile, this test was incomplete too
since libc implementations like musl has 64bit off_t by default on 32bit
systems and does not bundle[2] -D_LARGEFILE64_SOURCE under -D_GNU_SOURCE
like glibc, which means the compile now fails on musl because the cmake
check passes but we do not have _LARGEFILE64_SOURCE defined. Using the
*64 function was transitional anyways so use -D_FILE_OFFSET_BITS=64
instead
[1] 8db7e5e4ee
[2] https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D139752
If we don't use the index otherwise, if(IN_LIST) is more readable and
doesn't clutter the local scope with index variables.
This was pointed out by @beanz in D96670.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D142405
This reverts commit ae3e228af77fea9ff4c45cca88a7a0de2cad662b.
Seems that it may form a wrong command line for 32-bit Halide builds
`-D_FILE_OFFSET_BITS="64 -D_DEBUG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"` according to
