maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/tail-padding.cpp

35 lines
1.4 KiB
C++
Raw Normal View History

PR36992: do not store beyond the dsize of a class object unless we know the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
2018-04-06 04:52:58 +08:00
// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm -o - %s | FileCheck %s
// PR36992
namespace Implicit {
struct A { char c; A(const A&); };
struct B { int n; char c[3]; ~B(); };
struct C : B, virtual A {};
static_assert(sizeof(C) == sizeof(void*) + 8);
C f(C c) { return c; }
// CHECK: define {{.*}} @_ZN8Implicit1CC1EOS0_
Don't assume constructors return void. Should fix ARM buildbot. llvm-svn: 329449
2018-04-07 04:06:02 +08:00
// CHECK: call {{.*}} @_ZN8Implicit1AC2ERKS0_(
PR36992: do not store beyond the dsize of a class object unless we know the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
2018-04-06 04:52:58 +08:00
// Note: this must memcpy 7 bytes, not 8, to avoid trampling over the virtual base class.
Generalize test for 32-bit targets. llvm-svn: 329467
2018-04-07 08:28:32 +08:00
// CHECK: call void @llvm.memcpy.p0i8.p0i8.i{{32|64}}(i8* {{.*}}, i8* {{.*}}, i{{32|64}} 7, i1 false)
PR36992: do not store beyond the dsize of a class object unless we know the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
2018-04-06 04:52:58 +08:00
// CHECK: store i32 {{.*}} @_ZTVN8Implicit1CE
}
namespace InitWithinNVSize {
// This is the same as the previous test, except that the A base lies
// entirely within the nvsize of C. This makes it valid to copy at the
// full width.
struct A { char c; A(const A&); };
struct B { int n; char c[3]; ~B(); };
struct C : B, virtual A { char x; };
static_assert(sizeof(C) > sizeof(void*) + 8);
C f(C c) { return c; }
// CHECK: define {{.*}} @_ZN16InitWithinNVSize1CC1EOS0_
Don't assume constructors return void. Should fix ARM buildbot. llvm-svn: 329449
2018-04-07 04:06:02 +08:00
// CHECK: call {{.*}} @_ZN16InitWithinNVSize1AC2ERKS0_(
PR36992: do not store beyond the dsize of a class object unless we know the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
2018-04-06 04:52:58 +08:00
// This copies over the 'C::x' member, but that's OK because we've not initialized it yet.
Generalize test for 32-bit targets. llvm-svn: 329467
2018-04-07 08:28:32 +08:00
// CHECK: call void @llvm.memcpy.p0i8.p0i8.i{{32|64}}(i8* {{.*}}, i8* {{.*}}, i{{32|64}} 8, i1 false)
PR36992: do not store beyond the dsize of a class object unless we know the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
2018-04-06 04:52:58 +08:00
// CHECK: store i32 {{.*}} @_ZTVN16InitWithinNVSize1CE
// CHECK: store i8
}