clang++18 segfaults on templated code using noexcept #92133
Labels
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
crash
Prefer [crash-on-valid] or [crash-on-invalid]
needs-reduction
Large reproducer that should be reduced into a simpler form
Comments
github-actions
bot
added
the
clang
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Etienne (Ecordonnier)
Hello, clang++18.1.6 is segfaulting on my Ubuntu 23.10 machine while attempting to compile this code. I originally reproduced with meta-clang on clang versions 18.1.4 and 18.1.5.
The code compiles fine with clang++17.0.2 (from the Ubuntu 23.10 package). Clang logs after segfault: |
zyn0217
added
the
needs-reduction
|
Note that if I comment out the nested noexcept, it compiles: Also, I tested using "llvm.sh 19" and the code compiles with this version of clang19: |
Ecordonnier
changed the title
|
Reduced to: template<typename T>
struct A
{
template<typename... Ts>
static void f(Ts... ts) noexcept(noexcept((ts, ...)));
};
void (*x)(int) = A<int>::f<int>;This crash goes all the way back to clang 4.0 (see godbolt link), but it no longer happens on |
Yeah, that definitely looks like it would fix this. That is a somewhat common crash when we are trying to lookup a decl that isn't really there (the not LabelDecl is a pretty awful assert message). So we were presumably looking for a pack/type that wasn't actually inserted into the instantiated decls stack. But if we're skipping the pack instantiation here, this is fixed. Does the original reproducer still crash on Trunk? I fear that perhaps we missed instantiating/substituting a pack somewhere else, but if it is just in an exception specifier, I would consider this fixed. |
It does not :) (godbolt link) |
Thanks for checking! Yeah, i think this is fixed in trunk. I don't think it qualifies for fix in the 18 branch (though perhaps I could be convinced), but at the moment I'm happy with "fixed in trunk". |
|
What is the criteria for not backporting vs not backporting? Is it based on the limited impact? |
Effectively, this comes down to codeowner opinion. We have to balance the impact of the bug/regression (which seems fairly limited here), the size/impact of the actual patch (which in this case, is pretty sizable impact wise), and amount of releases after this (this would at best get to 18.1.6, which is an 'if necessary' only patch), plus time to next release branch (which is roughly in ~2 months). So from my perspective, we have: So I have 3 against, and 1 'middling'. I could perhaps squint on the impact, and have it be 2 against, 2 'middling', but even then I'd have a hard time judging this. So unless we (soon, as our last release date for 18 is on the 26th) have an outpouring of support from some large projects, I don't see this as being able to be cherry-picked to the release branch. |
|
@erichkeane My understanding is that the deadline to backport is... today. this is another good reason not to. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello, clang++18.1.6 is segfaulting on my Ubuntu 23.10 machine while attempting to compile this code. I originally reproduced with meta-clang on clang versions 18.1.4 and 18.1.5.
The code compiles fine with clang++17.0.2 (from the Ubuntu 23.10 package).
The zip file attached contains the c++ code involved reduced to a minimal example, as well as the clang segfault call-stack, and the files /tmp/test-XXXX.cpp and tmp/test-XXXX.sh which the clang logs requested to include with the bug report.
clang-bug-report.zip
Clang logs after segfault:
The text was updated successfully, but these errors were encountered: