[cmake] Restore exception flags in llvm-config --cxxflags #176195
Merged
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
aengelke
approved these changes
Jan 15, 2026
Contributor
There was a problem hiding this comment.
LGTM. The whole thing is just incredibly messy and if this causes breakage, let's not try to win points for purity here.
A summary of the messiness:
- -fno-exceptions/-fno-rtti are only exposed via llvm-config, not via CMake when linking against LLVM. CMake users have to add these manually.
- CMake by-default adds
/EHscfor MSVC (/GRwas dropped with CMake 3.20, which we require). - MSVC warns about option mismatch, this warning can't be disabled.
- One unittest unconditionally wants exceptions, with MSVC this forces us to do this per-target flag update and prevent us from just setting it in the global CMAKE_CXX_FLAGS.
- Many Linux distributions build with -frtti, because some users use rtti to avoid this incompatibility.
| endif() | ||
| elseif(MSVC) | ||
| if(MSVC) | ||
| list(APPEND LLVM_COMPILE_DEFINITIONS _HAS_EXCEPTIONS=0) |
Contributor
There was a problem hiding this comment.
Given that this is now the only use of LLVM_COMPILE_DEFINITIONS, just use target_compile_definitions(${name} PRIVATE _HAS_EXCEPTIONS=0) here?
Contributor
Author
|
/cherry-pick 9bbea75 |
Member
|
/pull-request #176328 |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/141/builds/14517 Here is the relevant piece of the build log for the reference |
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)
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.
rust-bors bot
pushed a commit
to rust-lang/rust
that referenced
this pull request
Jan 27, 2026
Update to LLVM 22 Scheduled release date: Feb 24 1.94 becomes stable: Mar 5 Changes: * Update to rc2, with one patch to work around our outdated illumos sysroot (rust-lang/llvm-project@41256ab). * Update the host toolchain as well, otherwise we lose cross-language LTO, in particular for jemalloc. * Adjust one loongarch assembly test. The split into r and s variants is based on the suggestion in #151134. Depends on: * [x] #151410 * [ ] #150756 * [x] llvm/llvm-project#175190 * [x] llvm/llvm-project#175912 * [x] llvm/llvm-project#175965 * [x] llvm/llvm-project#176195 * [x] llvm/llvm-project#157073 * [x] llvm/llvm-project#176421 * [x] llvm/llvm-project#176925 * [x] llvm/llvm-project#177187
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.
#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-rtticonfiguration 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-exceptionswhen using older deployment targets. In that configuration,-fno-exceptionsis required to interact with LLVM.