The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it. Relying on Sema's
computation seems much more reliable.
Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).
This does mean that we have a less portable rule for deciding
indirectness for swiftcall. I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.
This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime. It doesn't affect normal Swift
operation because we don't import code as C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328942 91177308-0d34-0410-b5e6-96231b3b80d8
We need to take type alignment padding into account whe computing physical
layouts.
The layout must be compatible with the input layout, offsets are defined in
terms of offsets within a packed struct which are computed in terms of the alloc
size of a type.
Usingthe store size we would insert padding for the following type for example:
struct {
int3 v;
long long l;
} __attribute((packed))
On x86-64 int3 is padded to int4 alignment. The swiftcc type would be
<{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>,
i64 }>.
The latter has i64 at offset 16 and the former at offset 20.
rdar://32618125
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305956 91177308-0d34-0410-b5e6-96231b3b80d8
Use iterator instead of address of element in vector
It is not valid to access one after the last element.
rdar://28759508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284150 91177308-0d34-0410-b5e6-96231b3b80d8
Fangrui Song