Front end crash with `const` qualifier on class member `operator new()` #79748

hgruniaux · 2024-01-28T13:40:12Z

Compiling the following C++ code (minimal reproducible example) with Clang:

#include <cstddef>

class Test {
 public:
  // The problem is the `const` qualifier. If it is removed, then the frontend does not crash.
  void* operator new(size_t bytes) const { return nullptr; }
};

int main() {
  new Test();
  return 0;
}

Gives the following stacktrace:

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: /usr/bin/clang++ -I/home/hgruniaux/CLionProjects/iris-cxx/inc -g -std=gnu++20 -fcolor-diagnostics -MD -MT CMakeFiles/iris_cxx.dir/src/main.cpp.o -MF CMakeFiles/iris_cxx.dir/src/main.cpp.o.d -o CMakeFiles/iris_cxx.dir/src/main.cpp.o -c /home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '/home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp'.
4.	Running pass 'X86 Assembly Printer' on function '@_ZNK4TestnwEm'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libLLVM-16.so.1    0x00007f01193c975a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 58
1  libLLVM-16.so.1    0x00007f01193c7994 llvm::sys::RunSignalHandlers() + 84
2  libLLVM-16.so.1    0x00007f0119306494
3  libc.so.6          0x00007f0117c42910
4  libLLVM-16.so.1    0x00007f01195155f4 llvm::MDString::getString() const + 4
5  libLLVM-16.so.1    0x00007f0119c9429a llvm::DwarfUnit::updateAcceleratorTables(llvm::DIScope const*, llvm::DIType const*, llvm::DIE const&) + 74
6  libLLVM-16.so.1    0x00007f0119c94419 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 153
7  libLLVM-16.so.1    0x00007f0119c9558a llvm::DwarfUnit::constructSubprogramArguments(llvm::DIE&, llvm::DITypeRefArray) + 282
8  libLLVM-16.so.1    0x00007f0119c9724d llvm::DwarfUnit::applySubprogramAttributes(llvm::DISubprogram const*, llvm::DIE&, bool) + 1197
9  libLLVM-16.so.1    0x00007f0119c92e45 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 293
10 libLLVM-16.so.1    0x00007f0119c936d6 llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) + 662
11 libLLVM-16.so.1    0x00007f0119c94503 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 387
12 libLLVM-16.so.1    0x00007f0119c92d65 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 69
13 libLLVM-16.so.1    0x00007f0119c6737f llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) + 79
14 libLLVM-16.so.1    0x00007f0119c780e1 llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) + 929
15 libLLVM-16.so.1    0x00007f0119c5ae84 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) + 100
16 libLLVM-16.so.1    0x00007f0119c441e7 llvm::AsmPrinter::emitFunctionBody() + 11303
17 libLLVM-16.so.1    0x00007f011bd1fbca
18 libLLVM-16.so.1    0x00007f011975fd9b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 635
19 libLLVM-16.so.1    0x00007f011950536d llvm::FPPassManager::runOnFunction(llvm::Function&) + 653
20 libLLVM-16.so.1    0x00007f011950b143 llvm::FPPassManager::runOnModule(llvm::Module&) + 51
21 libLLVM-16.so.1    0x00007f0119505a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 965
22 libclang-cpp.so.16 0x00007f012170877b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) + 3339
23 libclang-cpp.so.16 0x00007f0121a69f7f
24 libclang-cpp.so.16 0x00007f01207ddf32 clang::ParseAST(clang::Sema&, bool, bool) + 850
25 libclang-cpp.so.16 0x00007f012241d2a9 clang::FrontendAction::Execute() + 89
26 libclang-cpp.so.16 0x00007f0122398184 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 724
27 libclang-cpp.so.16 0x00007f0122496a64 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 660
28 clang++            0x00005566ba773d86 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 2374
29 clang++            0x00005566ba770e00
30 libclang-cpp.so.16 0x00007f0122070536
31 libLLVM-16.so.1    0x00007f0119306224 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 148
32 libclang-cpp.so.16 0x00007f012206fbe7 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const + 359
33 libclang-cpp.so.16 0x00007f012203ac86 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 854
34 libclang-cpp.so.16 0x00007f012203aeee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const + 158
35 libclang-cpp.so.16 0x00007f012205572e clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 334
36 clang++            0x00005566ba77058a clang_main(int, char**) + 11882
37 libc.so.6          0x00007f0117c280d0
38 libc.so.6          0x00007f0117c28189 __libc_start_main + 137
39 clang++            0x00005566ba76d3a5 _start + 37
clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Ubuntu clang version 16.0.6 (15)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

The used Clang version is 16.0.6. I have no tested if the bug is still there on more recent versions of Clang.

The text was updated successfully, but these errors were encountered:

hgruniaux · 2024-01-28T13:50:20Z

Bug reproduced in the last version of Clang on Godbolt:
https://godbolt.org/z/1nh8Y8qbj

GCC correctly emits an error and do not crash.

hgruniaux · 2024-01-28T13:52:10Z

According to tests on Godbolt, Clang 13.0.1 correctly compiled the code (without errors, which is not the same behavior as GCC) but Clang 14.0.0 crashed.

llvmbot · 2024-01-28T15:34:04Z

@llvm/issue-subscribers-debuginfo

Author: Hubert Gruniaux (hgruniaux)

Compiling the following C++ code (minimal reproducible example) with Clang: ```c++ #include <cstddef>

class Test {
public:
// The problem is the const qualifier. If it is removed, then the frontend does not crash.
void* operator new(size_t bytes) const { return nullptr; }
};

int main() {
new Test();
return 0;
}


Gives the following stacktrace:

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: /usr/bin/clang++ -I/home/hgruniaux/CLionProjects/iris-cxx/inc -g -std=gnu++20 -fcolor-diagnostics -MD -MT CMakeFiles/iris_cxx.dir/src/main.cpp.o -MF CMakeFiles/iris_cxx.dir/src/main.cpp.o.d -o CMakeFiles/iris_cxx.dir/src/main.cpp.o -c /home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp

<eof> parser at end of file
Code generation
Running pass 'Function Pass Manager' on module '/home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp'.
Running pass 'X86 Assembly Printer' on function '@_ZNK4TestnwEm'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it):
0 libLLVM-16.so.1 0x00007f01193c975a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 58
1 libLLVM-16.so.1 0x00007f01193c7994 llvm::sys::RunSignalHandlers() + 84
2 libLLVM-16.so.1 0x00007f0119306494
3 libc.so.6 0x00007f0117c42910
4 libLLVM-16.so.1 0x00007f01195155f4 llvm::MDString::getString() const + 4
5 libLLVM-16.so.1 0x00007f0119c9429a llvm::DwarfUnit::updateAcceleratorTables(llvm::DIScope const*, llvm::DIType const*, llvm::DIE const&) + 74
6 libLLVM-16.so.1 0x00007f0119c94419 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 153
7 libLLVM-16.so.1 0x00007f0119c9558a llvm::DwarfUnit::constructSubprogramArguments(llvm::DIE&, llvm::DITypeRefArray) + 282
8 libLLVM-16.so.1 0x00007f0119c9724d llvm::DwarfUnit::applySubprogramAttributes(llvm::DISubprogram const*, llvm::DIE&, bool) + 1197
9 libLLVM-16.so.1 0x00007f0119c92e45 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 293
10 libLLVM-16.so.1 0x00007f0119c936d6 llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) + 662
11 libLLVM-16.so.1 0x00007f0119c94503 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 387
12 libLLVM-16.so.1 0x00007f0119c92d65 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 69
13 libLLVM-16.so.1 0x00007f0119c6737f llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) + 79
14 libLLVM-16.so.1 0x00007f0119c780e1 llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) + 929
15 libLLVM-16.so.1 0x00007f0119c5ae84 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) + 100
16 libLLVM-16.so.1 0x00007f0119c441e7 llvm::AsmPrinter::emitFunctionBody() + 11303
17 libLLVM-16.so.1 0x00007f011bd1fbca
18 libLLVM-16.so.1 0x00007f011975fd9b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 635
19 libLLVM-16.so.1 0x00007f011950536d llvm::FPPassManager::runOnFunction(llvm::Function&) + 653
20 libLLVM-16.so.1 0x00007f011950b143 llvm::FPPassManager::runOnModule(llvm::Module&) + 51
21 libLLVM-16.so.1 0x00007f0119505a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 965
22 libclang-cpp.so.16 0x00007f012170877b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) + 3339
23 libclang-cpp.so.16 0x00007f0121a69f7f
24 libclang-cpp.so.16 0x00007f01207ddf32 clang::ParseAST(clang::Sema&, bool, bool) + 850
25 libclang-cpp.so.16 0x00007f012241d2a9 clang::FrontendAction::Execute() + 89
26 libclang-cpp.so.16 0x00007f0122398184 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 724
27 libclang-cpp.so.16 0x00007f0122496a64 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 660
28 clang++ 0x00005566ba773d86 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 2374
29 clang++ 0x00005566ba770e00
30 libclang-cpp.so.16 0x00007f0122070536
31 libLLVM-16.so.1 0x00007f0119306224 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 148
32 libclang-cpp.so.16 0x00007f012206fbe7 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, bool) const + 359
33 libclang-cpp.so.16 0x00007f012203ac86 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 854
34 libclang-cpp.so.16 0x00007f012203aeee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const + 158
35 libclang-cpp.so.16 0x00007f012205572e clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 334
36 clang++ 0x00005566ba77058a clang_main(int, char**) + 11882
37 libc.so.6 0x00007f0117c280d0
38 libc.so.6 0x00007f0117c28189 __libc_start_main + 137
39 clang++ 0x00005566ba76d3a5 _start + 37
clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Ubuntu clang version 16.0.6 (15)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


The used Clang version is 16.0.6. I have no tested if the bug is still there on more recent versions of Clang.
</details>

llvmbot · 2024-01-28T15:34:05Z

@llvm/issue-subscribers-backend-x86

Author: Hubert Gruniaux (hgruniaux)

Compiling the following C++ code (minimal reproducible example) with Clang: ```c++ #include <cstddef>

class Test {
public:
// The problem is the const qualifier. If it is removed, then the frontend does not crash.
void* operator new(size_t bytes) const { return nullptr; }
};

int main() {
new Test();
return 0;
}


Gives the following stacktrace:

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: /usr/bin/clang++ -I/home/hgruniaux/CLionProjects/iris-cxx/inc -g -std=gnu++20 -fcolor-diagnostics -MD -MT CMakeFiles/iris_cxx.dir/src/main.cpp.o -MF CMakeFiles/iris_cxx.dir/src/main.cpp.o.d -o CMakeFiles/iris_cxx.dir/src/main.cpp.o -c /home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp

<eof> parser at end of file
Code generation
Running pass 'Function Pass Manager' on module '/home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp'.
Running pass 'X86 Assembly Printer' on function '@_ZNK4TestnwEm'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it):
0 libLLVM-16.so.1 0x00007f01193c975a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 58
1 libLLVM-16.so.1 0x00007f01193c7994 llvm::sys::RunSignalHandlers() + 84
2 libLLVM-16.so.1 0x00007f0119306494
3 libc.so.6 0x00007f0117c42910
4 libLLVM-16.so.1 0x00007f01195155f4 llvm::MDString::getString() const + 4
5 libLLVM-16.so.1 0x00007f0119c9429a llvm::DwarfUnit::updateAcceleratorTables(llvm::DIScope const*, llvm::DIType const*, llvm::DIE const&) + 74
6 libLLVM-16.so.1 0x00007f0119c94419 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 153
7 libLLVM-16.so.1 0x00007f0119c9558a llvm::DwarfUnit::constructSubprogramArguments(llvm::DIE&, llvm::DITypeRefArray) + 282
8 libLLVM-16.so.1 0x00007f0119c9724d llvm::DwarfUnit::applySubprogramAttributes(llvm::DISubprogram const*, llvm::DIE&, bool) + 1197
9 libLLVM-16.so.1 0x00007f0119c92e45 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 293
10 libLLVM-16.so.1 0x00007f0119c936d6 llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) + 662
11 libLLVM-16.so.1 0x00007f0119c94503 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 387
12 libLLVM-16.so.1 0x00007f0119c92d65 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 69
13 libLLVM-16.so.1 0x00007f0119c6737f llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) + 79
14 libLLVM-16.so.1 0x00007f0119c780e1 llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) + 929
15 libLLVM-16.so.1 0x00007f0119c5ae84 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) + 100
16 libLLVM-16.so.1 0x00007f0119c441e7 llvm::AsmPrinter::emitFunctionBody() + 11303
17 libLLVM-16.so.1 0x00007f011bd1fbca
18 libLLVM-16.so.1 0x00007f011975fd9b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 635
19 libLLVM-16.so.1 0x00007f011950536d llvm::FPPassManager::runOnFunction(llvm::Function&) + 653
20 libLLVM-16.so.1 0x00007f011950b143 llvm::FPPassManager::runOnModule(llvm::Module&) + 51
21 libLLVM-16.so.1 0x00007f0119505a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 965
22 libclang-cpp.so.16 0x00007f012170877b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) + 3339
23 libclang-cpp.so.16 0x00007f0121a69f7f
24 libclang-cpp.so.16 0x00007f01207ddf32 clang::ParseAST(clang::Sema&, bool, bool) + 850
25 libclang-cpp.so.16 0x00007f012241d2a9 clang::FrontendAction::Execute() + 89
26 libclang-cpp.so.16 0x00007f0122398184 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 724
27 libclang-cpp.so.16 0x00007f0122496a64 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 660
28 clang++ 0x00005566ba773d86 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 2374
29 clang++ 0x00005566ba770e00
30 libclang-cpp.so.16 0x00007f0122070536
31 libLLVM-16.so.1 0x00007f0119306224 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 148
32 libclang-cpp.so.16 0x00007f012206fbe7 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, bool) const + 359
33 libclang-cpp.so.16 0x00007f012203ac86 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 854
34 libclang-cpp.so.16 0x00007f012203aeee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const + 158
35 libclang-cpp.so.16 0x00007f012205572e clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 334
36 clang++ 0x00005566ba77058a clang_main(int, char**) + 11882
37 libc.so.6 0x00007f0117c280d0
38 libc.so.6 0x00007f0117c28189 __libc_start_main + 137
39 clang++ 0x00005566ba76d3a5 _start + 37
clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Ubuntu clang version 16.0.6 (15)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


The used Clang version is 16.0.6. I have no tested if the bug is still there on more recent versions of Clang.
</details>

phoebewang · 2024-01-29T00:37:00Z

This should be diagnosed by front end.

to268 · 2024-01-29T17:39:46Z

This is clearly a case where we don't diagnose the issue in the Sema phase, by comparison with GCC.
https://godbolt.org/z/vYoPnjMcc
This issue should be labelled clang:frontend, but I do not have the rights.
CC: @AaronBallman

llvmbot · 2024-01-29T17:43:04Z

@llvm/issue-subscribers-clang-frontend

Author: Hubert Gruniaux (hgruniaux)

Compiling the following C++ code (minimal reproducible example) with Clang: ```c++ #include <cstddef>

class Test {
public:
// The problem is the const qualifier. If it is removed, then the frontend does not crash.
void* operator new(size_t bytes) const { return nullptr; }
};

int main() {
new Test();
return 0;
}


Gives the following stacktrace:

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: /usr/bin/clang++ -I/home/hgruniaux/CLionProjects/iris-cxx/inc -g -std=gnu++20 -fcolor-diagnostics -MD -MT CMakeFiles/iris_cxx.dir/src/main.cpp.o -MF CMakeFiles/iris_cxx.dir/src/main.cpp.o.d -o CMakeFiles/iris_cxx.dir/src/main.cpp.o -c /home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp

<eof> parser at end of file
Code generation
Running pass 'Function Pass Manager' on module '/home/hgruniaux/CLionProjects/iris-cxx/src/main.cpp'.
Running pass 'X86 Assembly Printer' on function '@_ZNK4TestnwEm'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it):
0 libLLVM-16.so.1 0x00007f01193c975a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 58
1 libLLVM-16.so.1 0x00007f01193c7994 llvm::sys::RunSignalHandlers() + 84
2 libLLVM-16.so.1 0x00007f0119306494
3 libc.so.6 0x00007f0117c42910
4 libLLVM-16.so.1 0x00007f01195155f4 llvm::MDString::getString() const + 4
5 libLLVM-16.so.1 0x00007f0119c9429a llvm::DwarfUnit::updateAcceleratorTables(llvm::DIScope const*, llvm::DIType const*, llvm::DIE const&) + 74
6 libLLVM-16.so.1 0x00007f0119c94419 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 153
7 libLLVM-16.so.1 0x00007f0119c9558a llvm::DwarfUnit::constructSubprogramArguments(llvm::DIE&, llvm::DITypeRefArray) + 282
8 libLLVM-16.so.1 0x00007f0119c9724d llvm::DwarfUnit::applySubprogramAttributes(llvm::DISubprogram const*, llvm::DIE&, bool) + 1197
9 libLLVM-16.so.1 0x00007f0119c92e45 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 293
10 libLLVM-16.so.1 0x00007f0119c936d6 llvm::DwarfUnit::constructTypeDIE(llvm::DIE&, llvm::DICompositeType const*) + 662
11 libLLVM-16.so.1 0x00007f0119c94503 llvm::DwarfUnit::createTypeDIE(llvm::DIScope const*, llvm::DIE&, llvm::DIType const*) + 387
12 libLLVM-16.so.1 0x00007f0119c92d65 llvm::DwarfUnit::getOrCreateSubprogramDIE(llvm::DISubprogram const*, bool) + 69
13 libLLVM-16.so.1 0x00007f0119c6737f llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) + 79
14 libLLVM-16.so.1 0x00007f0119c780e1 llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) + 929
15 libLLVM-16.so.1 0x00007f0119c5ae84 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) + 100
16 libLLVM-16.so.1 0x00007f0119c441e7 llvm::AsmPrinter::emitFunctionBody() + 11303
17 libLLVM-16.so.1 0x00007f011bd1fbca
18 libLLVM-16.so.1 0x00007f011975fd9b llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 635
19 libLLVM-16.so.1 0x00007f011950536d llvm::FPPassManager::runOnFunction(llvm::Function&) + 653
20 libLLVM-16.so.1 0x00007f011950b143 llvm::FPPassManager::runOnModule(llvm::Module&) + 51
21 libLLVM-16.so.1 0x00007f0119505a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 965
22 libclang-cpp.so.16 0x00007f012170877b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>) + 3339
23 libclang-cpp.so.16 0x00007f0121a69f7f
24 libclang-cpp.so.16 0x00007f01207ddf32 clang::ParseAST(clang::Sema&, bool, bool) + 850
25 libclang-cpp.so.16 0x00007f012241d2a9 clang::FrontendAction::Execute() + 89
26 libclang-cpp.so.16 0x00007f0122398184 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 724
27 libclang-cpp.so.16 0x00007f0122496a64 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 660
28 clang++ 0x00005566ba773d86 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 2374
29 clang++ 0x00005566ba770e00
30 libclang-cpp.so.16 0x00007f0122070536
31 libLLVM-16.so.1 0x00007f0119306224 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) + 148
32 libclang-cpp.so.16 0x00007f012206fbe7 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, bool) const + 359
33 libclang-cpp.so.16 0x00007f012203ac86 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 854
34 libclang-cpp.so.16 0x00007f012203aeee clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const + 158
35 libclang-cpp.so.16 0x00007f012205572e clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) + 334
36 clang++ 0x00005566ba77058a clang_main(int, char**) + 11882
37 libc.so.6 0x00007f0117c280d0
38 libc.so.6 0x00007f0117c28189 __libc_start_main + 137
39 clang++ 0x00005566ba76d3a5 _start + 37
clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Ubuntu clang version 16.0.6 (15)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


The used Clang version is 16.0.6. I have no tested if the bug is still there on more recent versions of Clang.
</details>

shafik · 2024-01-29T20:59:38Z

The diagnostic err_invalid_qualified_function_type happens in here:

llvm-project/clang/lib/Sema/SemaType.cpp

Lines 5916 to 5920 in e633807

    
           if (IsQualifiedFunction && 
        
               !(Kind == Member && !D.isExplicitObjectMemberFunction() && 
        
                 D.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static) && 
        
               !IsTypedefName && D.getContext() != DeclaratorContext::TemplateArg && 
        
               D.getContext() != DeclaratorContext::TemplateTypeArg) {

but we don't enter this block b/c

expr D.getDeclSpec().getStorageClassSpec()
(clang::DeclSpec::SCS) $8 = SCS_unspecified

whereas we are expecting DeclSpec::SCS_static. Either we need a finer grain check or the DecpSpec needs to be fixed.

CC @AaronBallman @erichkeane

Note if we explicitly add static we obtain the diagnostic we expect: https://godbolt.org/z/Mn46WeWjf

I wonder if we should be using D.isStaticMember() instead.

cor3ntin · 2024-01-29T22:08:52Z

Making the class version static ( above in that function) is probably the most correct solution indeed https://eel.is/c++draft/class.free

…

On Mon, Jan 29, 2024, 21:59 Shafik Yaghmour ***@***.***> wrote: The diagnostic err_invalid_qualified_function_type happens in here: https://github.com/llvm/llvm-project/blob/e633807a1fccbed91dbfe1fdc2c78adcaf21d99c/clang/lib/Sema/SemaType.cpp#L5916-L5920 but we don't enter this block b/c expr D.getDeclSpec().getStorageClassSpec()(clang::DeclSpec::SCS) $8 = SCS_unspecified whereas we are expecting DeclSpec::SCS_static. Either we need a finer grain check or the DecpSpec needs to be fixed. CC @AaronBallman <https://github.com/AaronBallman> @erichkeane <https://github.com/erichkeane> — Reply to this email directly, view it on GitHub <#79748 (comment)> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKX762RPEUQO7EI6XDZWRLYRAEUPBFKMF2HI4TJMJ2XIZLTTCBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVIYTSNJYHE4TQMRWG2SG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRTGYYDSNZSG4YDCMFENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWVDGNZTHA3DCNZRHA2KI3TBNVS2S2DBONPWYYLCMVWIFJLWMFWHKZNKGM3TMOJYHA3DMOJVURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UMZYGEYDCNJXGY2TJJDOMFWWLKLIMFZV63DBMJSWZLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOLYFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVA3TKOBSGE2DGMUCUR2HS4DFUVUXG43VMWSXMYLMOVS2UMRRGA2DCNRYGY3TNAVEOR4XAZNFNRQWEZLMUV3GC3DVMWVDCOJVHA4TSOBSGY3IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIZTMMBZG4ZDOMBRGCBKI5DZOBS2K3DBMJSWZJLWMFWHKZNKGM3TGOBWGE3TCOBUQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRTG43DSOBYGY3DSNMCUR2HS4DFUVWGCYTFNSSXMYLMOVS2UMZYGEYDCNJXGY2TJJ3UOJUWOZ3FOKTGG4TFMF2GK> . You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

shafik · 2024-01-30T00:06:38Z

It looks like the DeclSpec is pretty baked in, it was either purposeful or it will be hard to change, I believe.

if I change the condition to:

(!(Kind == Member && !D.isExplicitObjectMemberFunction() &&
          D.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static) ||
          (D.getContext() == clang::DeclaratorContext::Member && D.isStaticMember()))

This passes check-clang but is a bit ugly.

The original condition:

!(Kind == Member && !D.isExplicitObjectMemberFunction() &&
          D.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static)

Is a bit murky to me, so not clear to me if there is a simpler way to achieve this or not.

We should diagnose a const qualified member operator new but we fail to do so and this leads to crash during debug info generation. The fix is to diagnose this as ill-formed in the front-end. Fixes: llvm#79748

) We should diagnose a const qualified member operator new but we fail to do so and this leads to crash during debug info generation. The fix is to diagnose this as ill-formed in the front-end. Fixes: #79748

…m#80327) We should diagnose a const qualified member operator new but we fail to do so and this leads to crash during debug info generation. The fix is to diagnose this as ill-formed in the front-end. Fixes: llvm#79748

github-actions bot added the new issue label Jan 28, 2024

EugeneZelenko added backend:X86 debuginfo crash Prefer [crash-on-valid] or [crash-on-invalid] and removed new issue labels Jan 28, 2024

phoebewang added the clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer label Jan 29, 2024

RKSimon removed the backend:X86 label Jan 29, 2024

cor3ntin added the clang:frontend Language frontend issues, e.g. anything involving "Sema" label Jan 29, 2024

shafik added confirmed Verified by a second party and removed debuginfo labels Jan 29, 2024

shafik mentioned this issue Feb 1, 2024

[Clang][Sema] Fix crash with const qualified member operator new #80327

Merged

shafik closed this as completed in #80327 Feb 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Front end crash with `const` qualifier on class member `operator new()` #79748

Front end crash with `const` qualifier on class member `operator new()` #79748

hgruniaux commented Jan 28, 2024

hgruniaux commented Jan 28, 2024

hgruniaux commented Jan 28, 2024

llvmbot commented Jan 28, 2024

llvmbot commented Jan 28, 2024

phoebewang commented Jan 29, 2024

to268 commented Jan 29, 2024

llvmbot commented Jan 29, 2024

shafik commented Jan 29, 2024 •

edited

cor3ntin commented Jan 29, 2024 via email

shafik commented Jan 30, 2024

Front end crash with const qualifier on class member operator new() #79748

Front end crash with const qualifier on class member operator new() #79748

Comments

hgruniaux commented Jan 28, 2024

hgruniaux commented Jan 28, 2024

hgruniaux commented Jan 28, 2024

llvmbot commented Jan 28, 2024

llvmbot commented Jan 28, 2024

phoebewang commented Jan 29, 2024

to268 commented Jan 29, 2024

llvmbot commented Jan 29, 2024

shafik commented Jan 29, 2024 • edited

cor3ntin commented Jan 29, 2024 via email

shafik commented Jan 30, 2024

Front end crash with `const` qualifier on class member `operator new()` #79748

Front end crash with `const` qualifier on class member `operator new()` #79748

shafik commented Jan 29, 2024 •

edited