Commit Graph

52 Commits

Author SHA1 Message Date
Nico Weber b45ad7363c [clang] Use usual lit pattern for CLANG_DEFAULT_PIE_ON_LINUX and LLVM_WITH_Z3
See D28294 for context.

Differential Revision: https://reviews.llvm.org/D115751
2021-12-14 21:44:56 -05:00
Fangrui Song 1042de9058 [Driver] Add CLANG_DEFAULT_PIE_ON_LINUX to emulate GCC --enable-default-pie
In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,

* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.

This has been adopted by all(?) major distros.

I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).

This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.

Reviewed By: foutrelis, sylvestre.ledru, thesamesam

Differential Revision: https://reviews.llvm.org/D113372
2021-12-14 10:09:00 -08:00
Tom Stellard c7b3a91017 libclang.so: Make SONAME independent from LLVM version
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D105527
2021-07-26 16:37:26 -07:00
Tom Stellard 303ddb60a2 Fix utils/update_cc_test_checks/check-globals.test on stand-alone builds
We want to use LLVM_EXTERNAL_LIT if defined for the %lit substitution.

Reviewed By: jdenny

Differential Revision: https://reviews.llvm.org/D105873
2021-07-13 10:47:30 -07:00
Nico Weber fda790fbfa [clang] Make fewer assumptions about path to lit.site.cfg after 9eaf0d120d 2021-06-25 14:01:29 -04:00
Ella Ma 1d8fc086ae [clang][lit] Allow test cases to use the compiler that are used to compile Clang
Required by D83660.
Test cases may want to use the host compiler to compile some mocks for the
test case.

This patch adds two substitutions `%host_cc` and `%host_cxx` to use the host
compilers set via variable `CMAKE_C_COMPILER` and `CMAKE_CXX_COMPILER`.

Patch by Ella Ma!

Reviewed By: steakhal

Differential Revision: https://reviews.llvm.org/D98918
2021-03-24 11:32:57 +01:00
Markus Böck af2796c76d [test] Add ability to get error messages from CMake for errc substitution
Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used.

This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter.

If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions.

Differential Revision: https://reviews.llvm.org/D98278
2021-03-15 20:56:08 +01:00
Arthur Eubanks aafb366210 Reland [CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

Rename it internally to LLVM_ENABLE_NEW_PASS_MANAGER.

The #define for it is now in llvm-config.h.

The initial land accidentally set the value of
LLVM_ENABLE_NEW_PASS_MANAGER to the string
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER instead of its value.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072
2020-12-01 14:00:32 -08:00
Arthur Eubanks 806a76c001 Revert "[CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/"
The new pass manager was accidentally enabled by default with this change.

This reverts commit a36bd4c90d.
2020-12-01 13:12:12 -08:00
Arthur Eubanks a36bd4c90d [CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

The #define for it is now in llvm-config.h.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072
2020-12-01 11:42:17 -08:00
Nico Weber 61da501b6a clang/test: Remove platform-linker feature
By explicitly requesting the system linker with `-fuse-ld=`, the
tests are able to CHECK for the system linker even with
CLANG_DEFAULT_LINKER=lld.

Alternative to D74704.

Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 20:00:46 -05:00
Petr Hosek 31e5f7120b [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-08-11 20:22:11 -07:00
Petr Hosek a4d78d23c5 Revert "[CMake] Simplify CMake handling for zlib"
This reverts commit ccbc1485b5 which
is still failing on the Windows MLIR bots.
2020-08-08 17:08:23 -07:00
Petr Hosek ccbc1485b5 [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-08-08 16:44:08 -07:00
Christian Kühnel f3cc4df51d Revert "[CMake] Simplify CMake handling for zlib"
This reverts commit 1adc494bce.
This patch broke the Windows compilation on buildbot and pre-merge testing:
http://lab.llvm.org:8011/builders/mlir-windows/builds/5945
https://buildkite.com/llvm-project/llvm-master-build/builds/780
2020-08-07 09:36:49 +02:00
Petr Hosek 1adc494bce [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-08-05 16:07:11 -07:00
Hans Wennborg 3ab01550b6 Revert "[CMake] Simplify CMake handling for zlib"
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.

> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219

This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
2020-08-05 12:31:44 +02:00
Petr Hosek 10b1b4a231 [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-07-23 23:05:36 -07:00
Petr Hosek 38c71b7c85 Revert "[CMake] Simplify CMake handling for zlib"
This reverts commit 1d09ecf361 since
it breaks sanitizer bots.
2020-07-23 15:12:42 -07:00
Petr Hosek 1d09ecf361 [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-07-23 14:47:25 -07:00
Petr Hosek bcd27d9d73 Revert "[CMake] Simplify CMake handling for zlib"
This reverts commit 8c1a79dc12 because
it fails when zlib isn't installed.
2020-07-14 19:56:10 -07:00
Petr Hosek 8c1a79dc12 [CMake] Simplify CMake handling for zlib
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.

Differential Revision: https://reviews.llvm.org/D79219
2020-07-14 19:30:08 -07:00
Alex Lorenz 5eedf07ab9 [apple clang] disable in-process CC1 to preserve crashlog compatibility
The in-process CC1 currently doesn't interoperate with the macOS crash analytics,
which we would like to keep enabled for Apple clang. This commit restores the
out-of-process CC1 to the Apple clang CMake configuration for now.

Differential Revision: https://reviews.llvm.org/D80849
2020-06-05 10:55:42 -07:00
Saleem Abdulrasool 216833b32b Revert "Temporarily revert "build: use `find_package(Python3)` if available""
This reverts commit 35edd704e0.

Revert the revert and extend the patch further to account for the use of
the `PYTHONINTERP_FOUND`.
2020-04-29 01:38:08 +00:00
Eric Christopher 35edd704e0 Temporarily revert "build: use `find_package(Python3)` if available"
as it seems to be causing multiple people problems with running tests
and building.

This reverts commit c4c3883b00.
2020-04-28 16:41:22 -07:00
Saleem Abdulrasool c4c3883b00 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 09:24:27 -07:00
Saleem Abdulrasool be884b7935 Revert "build: use `find_package(Python3)` if available"
This reverts commit cd84bfb814.  Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.
2020-04-27 20:03:32 -07:00
Saleem Abdulrasool cd84bfb814 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 01:33:10 +00:00
Nico Weber 4d4fef22da Revert a few unsuccessful attempts at fixing bots.
I broke bots last week and tried a few things to fix them.
These were attempts that didn't help, so back them back out.

This reverts commit c7aff9a109.
This reverts commit 8838d6d356.
This reverts commit e875ba1509.
2020-04-13 17:09:21 -04:00
Nico Weber e875ba1509 Try again to get tests passing again on Windows.
Things pass locally, but some tests on some bots are still unhappy.
I'm not sure why. See if using forward slashes as before helps.
2020-04-02 20:00:38 -04:00
Nico Weber a16ba6fea2 Reland "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
The problem on Windows was that the \b in "..\bin" was interpreted
as an escape sequence. Use r"" strings to prevent that.

This reverts commit ab11b9eefa,
with raw strings in the lit.site.cfg.py.in files.

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 16:12:03 -04:00
Nico Weber ab11b9eefa Revert "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
This reverts commit fb80b6b2d5 and
follow-up 631ee8b24a.

Seems to not work on Windows:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/31684
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/6512

Let's revert while I investigate.
2020-04-02 15:00:09 -04:00
Nico Weber fb80b6b2d5 Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang
Currently, all generated lit.site.cfg files contain absolute paths.

This makes it impossible to build on one machine, and then transfer the
build output to another machine for test execution. Being able to do
this is useful for several use cases:

1. When running tests on an ARM machine, it would be possible to build
   on a fast x86 machine and then copy build artifacts over after building.

2. It allows running several test suites (clang, llvm, lld) on 3
   different machines, reducing test time from sum(each test suite time) to
   max(each test suite time).

This patch makes it possible to pass a list of variables that should be
relative in the generated lit.site.cfg.py file to
configure_lit_site_cfg(). The lit.site.cfg.py.in file needs to call
`path()` on these variables, so that the paths are converted to absolute
form at lit start time.

The testers would have to have an LLVM checkout at the same revision,
and the build dir would have to be at the same relative path as on the
builder.

This does not yet cover how to figure out which files to copy from the
builder machine to the tester machines. (One idea is to look at the
`--graphviz=test.dot` output and copy all inputs of the `check-llvm`
target.)

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 13:53:16 -04:00
Hans Wennborg 916be8fd6a Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"

This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.
2020-03-03 11:03:09 +01:00
serge-sans-paille 19c664f71e Fix typo in clang lit config
Typo introduced in e058667a2e
2020-02-26 10:37:04 +01:00
serge-sans-paille e058667a2e Support -fuse-ld=lld for riscv
Add a configure feature test to filter out tests that explicitly depend on platform linker.

Differential Revision: https://reviews.llvm.org/D74704
2020-02-26 10:20:20 +01:00
Saleem Abdulrasool abb0075306 build: reduce CMake handling for zlib
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This restores 68a235d07f,
e6c7ed6d21.  The problem with the windows
bot is a need for clearing the cache.
2020-01-02 11:19:12 -08:00
James Henderson e406cca5f9 Revert "build: reduce CMake handling for zlib"
This reverts commit 68a235d07f.

This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
2020-01-02 16:02:10 +00:00
Saleem Abdulrasool 68a235d07f build: reduce CMake handling for zlib
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
2020-01-01 16:36:59 -08:00
Richard Smith 26a92d5852 Improve behavior in the case of stack exhaustion.
Summary:
Clang performs various recursive operations (such as template instantiation),
and may use non-trivial amounts of stack space in each recursive step (for
instance, due to recursive AST walks). While we try to keep the stack space
used by such steps to a minimum and we have explicit limits on the number of
such steps we perform, it's impractical to guarantee that we won't blow out the
stack on deeply recursive template instantiations on complex ASTs, even with
only a moderately high instantiation depth limit.

The user experience in these cases is generally terrible: we crash with
no hint of what went wrong. Under this patch, we attempt to do better:

 * Detect when the stack is nearly exhausted, and produce a warning with a
   nice template instantiation backtrace, telling the user that we might
   run slowly or crash.

 * For cases where we're forced to trigger recursive template
   instantiation in arbitrarily-deeply-nested contexts, check whether
   we're nearly out of stack space and allocate a new stack (by spawning
   a new thread) after producing the warning.

Reviewers: rnk, aaron.ballman

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66361

llvm-svn: 369940
2019-08-26 18:18:07 +00:00
Leonard Chan e6d2c8dde6 [clang][NewPM] Fixing remaining -O0 tests that are broken under new PM
- CodeGen/flatten.c will fail under new PM becausec the new PM AlwaysInliner
  seems to intentionally inline functions but not call sites marked with
  alwaysinline (D23299)
- Tests that check remarks happen to check them for the inliner which is not
  turned on at O0. These tests just check that remarks work, but we can make
  separate tests for the new PM with -O1 so we can turn on the inliner and
  check the remarks with minimal changes.

Differential Revision: https://reviews.llvm.org/D62225

llvm-svn: 363846
2019-06-19 17:41:30 +00:00
Petr Hosek b7804ef3a7 [Analysis] Only run plugins tests if plugins are actually enabled
When plugins aren't enabled, don't try to run plugins tests. Don't
enable plugins unconditionally based on the platform, instead check
if LLVM shared library is actually being built which may not be the
case for every host configuration, even if the host itself supports
plugins.

This addresses test failures introduced by r360891/D59464.

Differential Revision: https://reviews.llvm.org/D62050

llvm-svn: 360991
2019-05-17 06:07:37 +00:00
Mikhail R. Gadelha db695c834f Moved everything SMT-related to LLVM and updated the cmake scripts.
Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 356929
2019-03-25 17:47:45 +00:00
Mikhail R. Gadelha 3289ccd848 This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.
and commit a1853e834c65751f92521f7481b15cf0365e796b.

They broke arm and aarch64

llvm-svn: 353590
2019-02-09 00:46:12 +00:00
Mikhail R. Gadelha eac500f0c3 Move the SMT API to LLVM
Moved everything SMT-related to LLVM and updated the cmake scripts.

Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 353373
2019-02-07 03:19:45 +00:00
Fangrui Song a4db70f945 Import lit.llvm after rC341132
llvm-svn: 341151
2018-08-31 00:24:36 +00:00
Nico Weber bc607e9252 Remove LIT_SITE_CFG_IN_FOOTER, clang
It's always replaced with the same (short) static string, so just put that
there directly.

No intended behavior change.
https://reviews.llvm.org/D51357

llvm-svn: 341132
2018-08-30 22:11:16 +00:00
Reid Kleckner b8c29d538b Fix lit fatal errors about requiring a USE_Z3_SOLVER param
llvm-svn: 339728
2018-08-14 21:15:57 +00:00
George Karpenkov 2997a3042e [analyzer] [NFC] Introduce separate targets for testing the analyzer: check-clang-analyzer and check-clang-analyzer-z3
Current testing setup for analyzer tests with Z3 is rather inconvenient:

There's no way to run the analyzer tests separately (I use
LIT_FILTER=Analysis ninja check-clang, but a direct target is nicer).

When Clang is built with Z3 support, there's no way to *not* run tests
with Z3 solver, and this is often desired, as tests with Z3 solver take
a very long time.

This patch introduces two extra targets:

 - check-clang-analyzer
 - check-clang-analyzer-z3

which solve those problems.

Differential Revision: https://reviews.llvm.org/D50594

llvm-svn: 339629
2018-08-13 23:12:43 +00:00
Nico Weber 82574aaac9 Remove unused lit setting, see https://reviews.llvm.org/D46619
llvm-svn: 331871
2018-05-09 12:38:51 +00:00