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

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34401

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
ABI.

### ONLINE COMPILER LINK:
https://godbolt.org/z/d4a5x8MYq

### SOURCE:
struct NonTriv {
  NonTriv(int);
  ~NonTriv();
};
extern "C" void LookForThis(void);
NonTriv::~NonTriv() {
  LookForThis();
}
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; }

### OPTIONS:
-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
0
  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
}

### OBSERVATIONS:
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>