Open Kurkin opened 2 years ago
@llvm/issue-subscribers-clang-codegen
I believe this was fixed by 45084eab5e6, @aeubanks can you please confirm? I think this fix should be merged to release/14.x
Ah no, it still asserts in the same way with quite recent 5c9f3ec4ad5 (llvmorg-15-init-11439-g5c9f3ec4ad5
) and -no-opaque-pointers
(which got enabled in 702d5de4380b1e1554e5b90863093c3a57f76f70 by @nikic):
$ ~/ins/llvmorg-15-init-11439-g5c9f3ec4ad5/bin/clang -cc1 -S -no-opaque-pointers pr54950.cpp
Assertion failed: (PtrTy->isOpaqueOrPointeeTypeMatches(IRFuncTy)), function EmitCall, file /home/dim/src/llvm/llvm-project/clang/lib/CodeGen/CGCall.cpp, line 4736.
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: /home/dim/ins/llvmorg-15-init-11439-g5c9f3ec4ad5/bin/clang -cc1 -S -no-opaque-pointers pr54950.cpp
1. <eof> parser at end of file
2. Per-file LLVM IR generation
3. pr54950.cpp:53:3: Generating code for declaration 'SF::SF'
#0 0x0000000003ce43b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/dim/ins/llvmorg-15-init-11439-g5c9f3ec4ad5/bin/clang+0x3ce43b8)
#1 0x0000000003ce21b8 llvm::sys::RunSignalHandlers() (/home/dim/ins/llvmorg-15-init-11439-g5c9f3ec4ad5/bin/clang+0x3ce21b8)
#2 0x0000000003ce4b50 SignalHandler(int) Signals.cpp:0:0
#3 0x000000082849ee00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Further minimized:
// clang -cc1 -S -no-opaque-pointers pr54950-min.cpp
struct I {
I(int, int, int);
};
struct SDH {
SDH(int, int, int, int);
};
struct SO : virtual I {
using super = I;
using super::super;
};
struct SF : SDH, SO {
SF() : I(1, 1, 1), SDH(1, 1, 1, 1), SO(1, 1, 1) {}
};
void r() { SF(); }
Also reproduces on current main
: https://clang.godbolt.org/z/xvsxjn576
I tried to migrate to the clang14 and got the following error on link stage with thin lto
and this crash with full lto
I tried to build clang in debug and got the following assert
note gdb shows slightly different stack
code to reproduce the problem