[llvm-bugs] [Bug 34401] Assertion failure/bad codegen: too many args w/inherited constructor from virtual base in ctor-initializer

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Nov 2 19:01:25 PDT 2021


hstong at ca.ibm.com changed:

           What    |Removed                     |Added
         Resolution|WORKSFORME                  |---
             Status|RESOLVED                    |REOPENED

--- Comment #2 from hstong at ca.ibm.com ---
This reproduces (with a slightly different assertion) with the same
instructions as was originally provided using a build with assertions enabled:
/llvm/clang/lib/CodeGen/CGCall.cpp:4669: clang::CodeGen::RValue
clang::CodeGen::CodeGenFunction::EmitCall(const clang::CodeGen::CGFunctionInfo
&, const clang::CodeGen::CGCallee &, clang::CodeGen::ReturnValueSlot, const
clang::CodeGen::CallArgList &, llvm::CallBase **, bool, clang::SourceLocation):
Assertion `IRFuncTy == TypeFromVal' failed.

The arguments to the inherited constructor are "passed into the void".

It seems that a different symptom of the same problem is how such arguments
with non-trivial destruction fail to get destroyed when compiling for the MS


struct NonTriv {
extern "C" void LookForThis(void);
NonTriv::~NonTriv() {
NonTriv LookForThat(void);
struct V { V() = default; V(NonTriv); };
struct A : virtual V {
  using V::V;
  A() : A(LookForThat()) { }
struct B : A { };
void foo() { B b; }

-target x86_64-pc-windows -emit-llvm -O -g0

### IR output (snippet):
define dso_local void @"?foo@@YAXXZ"() local_unnamed_addr #2 personality i32
(...)* @__CxxFrameHandler3 {
  %1 = alloca %struct.NonTriv, align 1
  %2 = getelementptr inbounds %struct.NonTriv, %struct.NonTriv* %1, i64 0, i32
  call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %2)
  call void @"?LookForThat@@YA?AUNonTriv@@XZ"(%struct.NonTriv* nonnull
sret(%struct.NonTriv) align 1 %1)
  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %2)
  ret void

It appears that there is no mechanism in the above by which the NonTriv
temporary is destroyed.

Aside: I will open a GCC defect for its failure to process the side-effects of
the argument initialization.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20211103/233ee45e/attachment.html>

More information about the llvm-bugs mailing list