| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
|
|
|
|
|
| |
C++-specific anymore.
llvm-svn: 329513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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++.
llvm-svn: 328942
|
|
|
|
|
|
| |
indirectly and expose that API externally.
llvm-svn: 321957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 305956
|
|
|
|
|
|
| |
register
llvm-svn: 288394
|
|
|
|
|
|
|
|
|
|
| |
Use iterator instead of address of element in vector
It is not valid to access one after the last element.
rdar://28759508
llvm-svn: 284150
|
|
|
|
|
|
| |
This is usefull for determining whether components overlap.
llvm-svn: 283932
|
|
|
|
| |
llvm-svn: 265782
|
|
|
|
| |
llvm-svn: 265355
|
|
|
|
|
|
| |
it was supposed to have been used.
llvm-svn: 265344
|
|
llvm-svn: 265324
|