ICE when returning the captured reference in the deducing this lambda #79754
Labels
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
crash
Prefer [crash-on-valid] or [crash-on-invalid]
lambda
C++11 lambda expressions
Comments
EugeneZelenko
added
clang:codegen
crash
|
@llvm/issue-subscribers-clang-codegen Author: Hewill Kang (hewillk)
```cpp
int main() {
int x = 42;
auto l = [&x](this auto&& self, int n) {
return x;
};
l(10);
}
```
https://godbolt.org/z/bdvKn9M6T
|
|
Reduced: https://godbolt.org/z/fYY43ce4n void f() {
int x;
[&x](this auto&&) {return x;}();
}Hit reachable: undeduced type in IR-generation
UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:234!Backtrace: PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++23 <source>
1. <eof> parser at end of file
2. <source>:1:6: LLVM IR generation of declaration 'f'
3. <source>:1:6: Generating code for declaration 'f'
#0 0x0000000003879a78 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3879a78)
#1 0x000000000387775c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x387775c)
#2 0x00000000037c04d8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x00007fbcd2642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x00007fbcd26969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x00007fbcd2642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x00007fbcd26287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x00000000037cb76a (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x37cb76a)
#8 0x0000000003c01d9a clang::CodeGen::CodeGenFunction::getEvaluationKind(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c01d9a)
#9 0x0000000003f7a381 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f7a381)
#10 0x0000000003f9bd5b clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f9bd5b)
#11 0x0000000003b9c8a5 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3b9c8a5)
#12 0x0000000003ba358c clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3ba358c)
#13 0x0000000003c03332 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c03332)
#14 0x0000000003c16584 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c16584)
#15 0x0000000003c79452 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c79452)
#16 0x0000000003c73d55 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c73d55)
#17 0x0000000003c74353 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c74353)
#18 0x0000000003c7df03 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0
#19 0x00000000041062e6 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#20 0x00000000040f73b8 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x40f73b8)
#21 0x00000000060a5104 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x60a5104)
#22 0x0000000004103ef8 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4103ef8)
#23 0x0000000004372779 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4372779)
#24 0x00000000042f23de clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x42f23de)
#25 0x0000000004452e1e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4452e1e)
#26 0x0000000000c131d6 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0xc131d6)
#27 0x0000000000c0aa1a ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#28 0x0000000004145439 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#29 0x00000000037c0984 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x37c0984)
#30 0x0000000004145a2f clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#31 0x000000000410d795 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x410d795)
#32 0x000000000410e1fd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x410e1fd)
#33 0x0000000004116135 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4116135)
#34 0x0000000000c1058c clang_main(int, char**, llvm::ToolContext const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0xc1058c)
#35 0x0000000000b078d4 main (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0xb078d4)
#36 0x00007fbcd2629d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#37 0x00007fbcd2629e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#38 0x0000000000c0a4fe _start (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0xc0a4fe)
clang++: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Compiler returned: 134 |
|
This is also fixed by #84473 |
Sirraide
added a commit
to Sirraide/llvm-project
that referenced
this issue
Mar 23, 2024
Sirraide
added a commit
that referenced
this issue
Apr 9, 2024
…ect parameter (#84473) This fixes some problems wrt dependence of captures in lambdas with an explicit object parameter. [temp.dep.expr] states that > An id-expression is type-dependent if [...] its terminal name is > - associated by name lookup with an entity captured by copy > ([expr.prim.lambda.capture]) in a lambda-expression that has > an explicit object parameter whose type is dependent [dcl.fct]. There were several issues with our implementation of this: 1. we were treating by-reference captures as dependent rather than by-value captures; 2. tree transform wasn't checking whether referring to such a by-value capture should make a DRE dependent; 3. when checking whether a DRE refers to such a by-value capture, we were only looking at the immediately enclosing lambda, and not at any parent lambdas; 4. we also forgot to check for implicit by-value captures; 5. lastly, we were attempting to determine whether a lambda has an explicit object parameter by checking the `LambdaScopeInfo`'s `ExplicitObjectParameter`, but it seems that that simply wasn't set (yet) by the time we got to the check. All of these should be fixed now. This fixes #70604, #79754, #84163, #84425, #86054, #86398, and #86399.
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Hewill Kang (hewillk)
```cpp
int main() {
int x = 42;
auto l = [&x](this auto&& self, int n) {
return x;
};
l(10);
}
```
https://godbolt.org/z/bdvKn9M6T
|
erikolofsson
pushed a commit
to Malterlib/llvm-project
that referenced
this issue
May 11, 2024
…ect parameter (llvm#84473) This fixes some problems wrt dependence of captures in lambdas with an explicit object parameter. [temp.dep.expr] states that > An id-expression is type-dependent if [...] its terminal name is > - associated by name lookup with an entity captured by copy > ([expr.prim.lambda.capture]) in a lambda-expression that has > an explicit object parameter whose type is dependent [dcl.fct]. There were several issues with our implementation of this: 1. we were treating by-reference captures as dependent rather than by-value captures; 2. tree transform wasn't checking whether referring to such a by-value capture should make a DRE dependent; 3. when checking whether a DRE refers to such a by-value capture, we were only looking at the immediately enclosing lambda, and not at any parent lambdas; 4. we also forgot to check for implicit by-value captures; 5. lastly, we were attempting to determine whether a lambda has an explicit object parameter by checking the `LambdaScopeInfo`'s `ExplicitObjectParameter`, but it seems that that simply wasn't set (yet) by the time we got to the check. All of these should be fixed now. This fixes llvm#70604, llvm#79754, llvm#84163, llvm#84425, llvm#86054, llvm#86398, and llvm#86399.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://godbolt.org/z/bdvKn9M6T
The text was updated successfully, but these errors were encountered: