[LLVM][CMake][NFC] Use generator expression to separate CXXFLAGS #173869
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This avoids looking at the individual sources for mixed C/C++ libraries. The previous code was written ~2014. Generator expressions were added in CMake 3.3 (2015). We currently require CMake 3.20 and therefore can rely on more modern features.
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/27/builds/20837 Here is the relevant piece of the build log for the reference |
Contributor
|
We have a bot to build the rust compiler with LLVM close to HEAD. Looks like starting from this commit, we're seeing some new linker errors like: Some sort of RTTI mismatch between how we build LLVM and the rust llvm-wrapper. The builder uses this configuration: Adding |
Contributor
|
@krasimirgg Rust shouldn't need LLVM built with RTTI. I'm not sure how this PR changed things. It looks like https://github.com/rust-lang/rust/blob/main/compiler/rustc_llvm/build.rs (the LLVM bindings build) doesn't set It would be good to get a full build log with the compiler invocations, so the used flags are visible. |
Contributor
Author
|
llvm-config uses And this amount of trouble just so that two unittests (/flang/unittests/Evaluate, /clang/unittests/Interpreter/ExceptionTests) can compile with exceptions (which, btw, also seem to work fine without RTTI) -- otherwise we could just set the flags globally and wouldn't need this llvm_update_compile_flags hack. |
Contributor
Author
|
A tangentially related questions is whether (And when using |
aengelke
added a commit
that referenced
this pull request
Jan 1, 2026
Fix for #173869. If there's no strong reason, we should get rid of per-target RTTI later.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 1, 2026
Fix for llvm/llvm-project#173869. If there's no strong reason, we should get rid of per-target RTTI later.
ronlieb
pushed a commit
to ROCm/llvm-project
that referenced
this pull request
Jan 2, 2026
Fix for llvm#173869. If there's no strong reason, we should get rid of per-target RTTI later.
mahesh-attarde
pushed a commit
to mahesh-attarde/llvm-project
that referenced
this pull request
Jan 6, 2026
…m#173869) This avoids looking at the individual sources for mixed C/C++ libraries. The previous code was written ~2014. Generator expressions were added in CMake 3.3 (2015). We currently require CMake 3.20 and therefore can rely on more modern features. Apart from simplifying the code, this is preliminary work to make more use of pre-compiled headers (llvm#173868).
mahesh-attarde
pushed a commit
to mahesh-attarde/llvm-project
that referenced
this pull request
Jan 6, 2026
Fix for llvm#173869. If there's no strong reason, we should get rid of per-target RTTI later.
navaneethshan
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jan 8, 2026
Fix for llvm/llvm-project#173869. If there's no strong reason, we should get rid of per-target RTTI later.
navaneethshan
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jan 9, 2026
Fix for llvm/llvm-project#173869. If there's no strong reason, we should get rid of per-target RTTI later. (cherry picked from commit d1b88ca)
nikic
added a commit
that referenced
this pull request
Jan 16, 2026
#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then #174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 16, 2026
…(#176195) llvm/llvm-project#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm/llvm-project#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM.
kkwli
pushed a commit
to kkwli/llvm-project
that referenced
this pull request
Jan 16, 2026
llvm#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM.
Priyanshu3820
pushed a commit
to Priyanshu3820/llvm-project
that referenced
this pull request
Jan 18, 2026
llvm#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM.
c-rhodes
pushed a commit
to llvmbot/llvm-project
that referenced
this pull request
Jan 19, 2026
llvm#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM. (cherry picked from commit 9bbea75)
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 19, 2026
…(#176195) llvm/llvm-project#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm/llvm-project#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM. (cherry picked from commit 9bbea75)
BStott6
pushed a commit
to BStott6/llvm-project
that referenced
this pull request
Jan 22, 2026
llvm#173869 accidentally dropped rtti and eh flags from `llvm-config --cxxflags`. Then llvm#174084 restored the rtti flags. The eh flags were not included with the rationale that they are not ABI relevant. This PR restores the eh flags as well. While they are not strictly necessary, I believe that code that directly interfaces with LLVM almost certainly does not want to build with exceptions if LLVM is not built with exceptions. Building in the peculiar `-fexceptions -fno-rtti` configuration is rarely useful and likely not intended. On MacOS, this is also relevant because it's not possible to use C++17 headers without `-fno-exceptions` when using older deployment targets. In that configuration, `-fno-exceptions` is required to interact with LLVM.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This avoids looking at the individual sources for mixed C/C++ libraries.
The previous code was written ~2014. Generator expressions were added in CMake 3.3 (2015). We currently require CMake 3.20 and therefore can rely on more modern features.
Apart from simplifying the code, this is preliminary work to make more use of pre-compiled headers (#173868).