Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICE: passing the result of a consteval function to another consteval function is crashing Clang #51695

Closed
Ivan171 opened this issue Oct 29, 2021 · 6 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla c++20 clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party consteval C++20 consteval crash Prefer [crash-on-valid] or [crash-on-invalid] duplicate Resolved as duplicate

Comments

@Ivan171
Copy link

Ivan171 commented Oct 29, 2021

Godbolt

Bugzilla Link 52353
Version trunk
OS Windows NT
CC @AaronBallman,@Ivan171,@zygoloid

Extended Description

=== version
$ clang++.exe --version
clang version 14.0.0 (https://github.com/llvm/llvm-project abdb82b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Dev\LLVM\bin

=== repro
$ type ice.cpp
template
struct type_t {};

template <typename...>
struct list_t {};

template <typename T, typename... Ts>
consteval auto pop_front(list_t<T, Ts...>) -> auto {
return list_t<Ts...>{};
}

template <typename... Ts, typename F>
consteval auto apply(list_t<Ts...>, F fn) -> auto {
return fn(type_t{}...);
}

void test() {
apply(
pop_front(list_t<char, char>{}),
[]<typename... Us>(type_t...) {
return false;
});
}

$ clang++.exe -std=c++20 ice.cpp
ice.cpp:18:3: warning: expression result unused [-Wunused-value]
apply(
^~~~~~
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run scri
pt.
Stack dump:
0. Program arguments: C:\Dev\LLVM\bin\clang++.exe -cc1 -triple x86_64-pc-windows-msvc19.29.30037 -emit-obj -mrelax-all -m
incremental-linker-compatible --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ice.c
pp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -fno-rounding-math -mconstructor-aliases -funwind-tables=
2 -target-cpu x86-64 -tune-cpu generic -fcoverage-compilation-dir=C:\Users\IVAN\Desktop\peg\build -resource-dir C:\Dev\LLVM
\lib\clang\14.0.0 -internal-isystem C:\Dev\LLVM\lib\clang\14.0.0\include -internal-isystem "C:\Program Files (x86)\Micr
osoft Visual Studio 2019\VC\Tools\MSVC\14.29.30037\ATLMFC\include" -internal-isystem "C:\Program Files (x86)\Microsoft Vis
ual Studio 2019\VC\Tools\MSVC\14.29.30037\include" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.
0.19041.0\ucrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" -internal-isystem "C
:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" -internal-isystem "C:\Program Files (x86)\Windows Kits\10
\include\10.0.19041.0\winrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" -std
=c++20 -fdeprecated-macro -fdebug-compilation-dir=C:\Users\IVAN\Desktop\peg\build -ferror-limit 19 -fmessage-length=130 -fno-
use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.29.30037 -fdelayed-template-parsing -fno-implicit-
modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -o C:\Users\IVAN\AppData\Local\Temp\ice-1a857b.o -x c++
ice.cpp

  1.  <eof> parser at end of file
    
  2.  ice.cpp:17:13: parsing function body 'test'
    

0x00007FF65B2A6AFA (0x0000000000000000 0x0000000000000000 0x0000000000000068 0x0000000000000000)
0x00007FF65B27D237 (0x0000003ABCD8B890 0x00000191E1C45940 0x00000191E1C45940 0x00007FF65CABE420)
0x00007FF65B278925 (0x00008A62DA3A4C5B 0x00000191E1BE2140 0x0000000000000100 0x0000000000000000)
0x00007FF65B2784F1 (0x00008A62DA3A4401 0x00007FF600000000 0x0000000000000100 0x00000191E1BECD10)
0x00007FF65B8CEEF3 (0x00000000000001CA 0x0000000000000154 0x0000003ABCD8C4D0 0x0000000000000154)
0x00007FF65B59C379 (0x0000003ABCD8C508 0x0000003ABCD8C5E0 0x0000003ABCD8C5D0 0x00007FF65B599465)
0x00007FF65C78CDBE (0x0000019100000000 0x0000000000000000 0x0000003ABCD8D101 0x00000191E1B35810)
0x00007FF65C4493D9 (0x0000003ABCD8D10A 0x0000003ABCD8D2E0 0x0000003ABCD8D0F8 0x00007FF65C70DDF1)
0x00007FF65C74165D (0x00000191E1B7FCD0 0x00007FF659E04600 0x0000003ABCD8D2B0 0x00000191E1C300A0)
0x00007FF65C4484BC (0x00000191E1B73C30 0x00007FF65AA0DC83 0x00000191E1C32D40 0x0000000000000008)
0x00007FF65C447E9C (0x00007FF600000028 0x0000000000000009 0x00007FF65D3554F9 0x0000000100000009)
0x00007FF65C446A31 (0x00000191E1C3B780 0x00008A62DA3A2FDB 0x00000191E1C3B780 0x00000191E1C3B780)
0x00007FF65C44498B (0x0000003ABCD8DA18 0x0000003ABCD8DA08 0x0000003ABCD8DA08 0x00007FF659DF696A)
0x00007FF65BA4C11E (0x00007FF65D400800 0x00008A62DA3A2DDB 0x2D646E756F72522D 0x3163632D70697274)
0x00007FF65AADA092 (0x00000191E1AF5D30 0x00000191E1AF7C30 0x00000191E1B65B60 0x00007FF659E881A9)
0x00007FF659DF896D (0x00000191E1AF8840 0x00000191E1B65B60 0x00000191E1B669F0 0x00000191E1B356F0)
0x00007FF659E888BE (0x00000191E1B1DC90 0x0000003ABCD8DE50 0x00000191E1B35FD0 0x00007FFDF50000F5)
0x00007FF659827B8A (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FF659824A2F (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FF659824832 (0x0000000000000000 0x00007FF65CA97859 0x0000000000000000 0x0000000000000000)
0x00007FF65CA977E0 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0x00007FFD64947BD4 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 byt
es(s)
0x00007FFD6590CED1 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 byte
s(s)
clang++: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 14.0.0 (https://github.com/llvm/llvm-project abdb82b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Dev\LLVM\bin
clang++: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: C:\Users\IVAN\AppData\Local\Temp\ice-f711d4.cpp
clang++: note: diagnostic msg: C:\Users\IVAN\AppData\Local\Temp\ice-f711d4.sh
clang++: note: diagnostic msg:


=== notes

If I replace pop_front(list_t<char, char>{}) by list_t{} directly, it works as expected.

@Ivan171
Copy link
Author

Ivan171 commented Oct 29, 2021

This doesn't work either:

void test() {
auto constexpr l = pop_front(list_t<char, char>{});
apply(
l,
[]<typename... Us>(type_t...) {
return false;
});
}

@AaronBallman
Copy link
Collaborator

I can confirm this is happening on trunk. The full stack trace is:

Clang++: /root/llvm-project/clang/lib/Sema/SemaExpr.cpp:16774: void RemoveNestedImmediateInvocation(clang::Sema&, clang::Sema::ExpressionEvaluationContextRecord&, llvm::SmallVectorTemplateCommon<llvm::PointerIntPair<clang::ConstantExpr*, 1>, void>::reverse_iterator): Assertion `Res.isUsable()' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -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++20 -Wall -pedantic

  1. parser at end of file
  2. :17:13: parsing function body 'test'

#​0 0x000055fa452b23ff PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#​1 0x000055fa452b01f0 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x38b01f0)
#​2 0x000055fa451f4028 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#​3 0x00007f719ae603c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#​4 0x00007f719a92f18b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
#​5 0x00007f719a90e859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859)
#​6 0x00007f719a90e729 (/lib/x86_64-linux-gnu/libc.so.6+0x25729)
#​7 0x00007f719a91ff36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#​8 0x000055fa475719d2 clang::Sema::PopExpressionEvaluationContext() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x5b719d2)
#​9 0x000055fa47417237 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x5a17237)
#​10 0x000055fa4725a6bf clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x585a6bf)
#​11 0x000055fa471beb84 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57beb84)
#​12 0x000055fa471e0c92 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57e0c92)
#​13 0x000055fa471bad69 clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57bad69)
#​14 0x000055fa471bb4b1 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.280) Parser.cpp:0:0
#​15 0x000055fa471bb6a0 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57bb6a0)
#​16 0x000055fa471bc2f9 clang::Parser::ParseTopLevelDecl(clang::OpaquePtrclang::DeclGroupRef&, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57bc2f9)
#​17 0x000055fa471b2469 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x57b2469)
#​18 0x000055fa462ec8d8 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x48ec8d8)
#​19 0x000055fa45c19321 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4219321)
#​20 0x000055fa45bb57ca clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x41b57ca)
#​21 0x000055fa45ce8e03 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x42e8e03)
#​22 0x000055fa42d03c4c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x1303c4c)
#​23 0x000055fa42cff049 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#​24 0x000055fa45a661d5 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, bool) const::'lambda'()>(long) Job.cpp:0:0
#​25 0x000055fa451f4613 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x37f4613)
#​26 0x000055fa45a68554 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4068554)
#​27 0x000055fa45a3e0ba clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x403e0ba)
#​28 0x000055fa45a3ed4f clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x403ed4f)
#​29 0x000055fa45a47b1a clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4047b1a)
#​30 0x000055fa42c281c2 main (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x12281c2)
#​31 0x00007f719a9100b3 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b3)
#​32 0x000055fa42cfebba _start (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x12febba)
clang-14: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Compiler returned: 134

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 11, 2021
@llvmbot llvmbot added the confirmed Verified by a second party label Jan 26, 2022
@usx95 usx95 added crash Prefer [crash-on-valid] or [crash-on-invalid] consteval C++20 consteval labels Aug 20, 2022
@usx95
Copy link
Contributor

usx95 commented Aug 29, 2022

Reduced

consteval bool zero() { return false; }

template <typename F>
consteval bool foo(bool, F) {
    return true;
}

bool test() {
    return foo(zero(), []() { return true; });
}

Moving the lambda to a constexpr variable resolves the crash (even in the initial report).

@EugeneZelenko EugeneZelenko added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Aug 29, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Aug 29, 2022

@llvm/issue-subscribers-clang-frontend

@usx95 usx95 added c++20 and removed c++20 labels Aug 29, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Aug 29, 2022

@llvm/issue-subscribers-c-20

@usx95
Copy link
Contributor

usx95 commented Aug 29, 2022

After looking at the reduced example, the core issue here is same as #56183 .

Marking this as duplicate since that bug has more activity.

Duplicate of #56183

@usx95 usx95 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 29, 2022
@usx95 usx95 added the duplicate Resolved as duplicate label Aug 29, 2022
@usx95 usx95 self-assigned this Aug 30, 2022
usx95 added a commit that referenced this issue Sep 2, 2022
…l fns.

As discussed in this [comment](#56183 (comment)),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.

This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`

While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)

Fixes: #56183
Fixes: #51695
Fixes: #50455
Fixes: #54872
Fixes: #54587

Differential Revision: https://reviews.llvm.org/D132945
usx95 added a commit to usx95/llvm-project that referenced this issue Sep 6, 2022
…l fns.

As discussed in this [comment](llvm#56183 (comment)),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.

This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`

While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)

Fixes: llvm#56183
Fixes: llvm#51695
Fixes: llvm#50455
Fixes: llvm#54872
Fixes: llvm#54587

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

(cherry picked from commit e7eec38)
tru pushed a commit to llvm/llvm-project-release-prs that referenced this issue Sep 8, 2022
…l fns.

As discussed in this [comment](llvm/llvm-project#56183 (comment)),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.

This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`

While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)

Fixes: llvm/llvm-project#56183
Fixes: llvm/llvm-project#51695
Fixes: llvm/llvm-project#50455
Fixes: llvm/llvm-project#54872
Fixes: llvm/llvm-project#54587

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

(cherry picked from commit e7eec38)
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
…l fns.

As discussed in this [comment](llvm/llvm-project#56183 (comment)),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.

This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`

While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)

Fixes: llvm/llvm-project#56183
Fixes: llvm/llvm-project#51695
Fixes: llvm/llvm-project#50455
Fixes: llvm/llvm-project#54872
Fixes: llvm/llvm-project#54587

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

(cherry picked from commit e7eec38246560781e0a4020b19c7eb038a8c5655)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++20 clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party consteval C++20 consteval crash Prefer [crash-on-valid] or [crash-on-invalid] duplicate Resolved as duplicate
Projects
Status: Done
Development

No branches or pull requests

5 participants