more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
llvm-svn: 117147
by marking the decl invalid isn't. Make some steps towards supporting these
and then hastily shut them down at the last second by marking them as
unsupported.
llvm-svn: 116661
arguments in either the placement or constructor arguments. This is
important if the default arguments refer to a declaration or create a
temporary.
llvm-svn: 115700
-Wpadded warns when undesired padding is introduced in a struct. (rdar://7469556)
-Wpacked warns if a struct is given the packed attribute, but the packed attribute has no effect
on the layout or the size of the struct. Such structs may be mis-aligned for little benefit.
The warnings are emitted at the point where layout is calculated, that is at RecordLayoutBuilder.
To avoid calculating the layouts of all structs regardless of whether they are needed or not,
I let the layouts be lazily constructed when needed. This has the disadvantage that the above warnings
will be emitted only when they are used for IR gen, and not e.g with -fsyntax-only:
$ cat t.c
struct S {
char c;
int i;
};
void f(struct S* s) {}
$ clang -fsyntax-only -Wpadded t.c
$ clang -c -Wpadded t.c -o t.o
t.c:3:7: warning: padding struct 'struct S' with 3 bytes to align 'i' [-Wpadded]
int i;
^
1 warning generated.
This is a good tradeoff between providing the warnings and not calculating layouts for all
structs in case the user has enabled a couple of rarely used warnings.
llvm-svn: 114544
LHS and when conditional expression is an array. Since
it will be decayed, saved expression must be saved with
decayed expression. This is necessary to preserve semantics
of this extension (and prevent an IRGen crash which expects
an array to always be decayed). I am sure there will be other
cases in c++ (aggregate conditionals for example) when saving of the
expression must happen after some transformation on conditional
expression has happened.
Doug, please review. Fixes // rdar://8446940
llvm-svn: 114296
the bases are completely initialized. This won't work --- base
initializer expressions can rely on the vtables having been set up.
Check for uses of 'this' in the initializers and force a vtable
initialization if found.
This might not be good enough; we might need to extend this to handle
the possibility of arbitrary code finding an external reference to this
(not yet completely-constructed!) object and accessing through it,
in which case we'll probably find ourselves doing a lot more unnecessary
stores.
llvm-svn: 114153
the cleanup might not be dominated by the allocation code.
In this case, we have to store aside all the delete arguments
in case we need them later. There's room for optimization here
in cases where we end up not actually needing the cleanup in
different branches (or being able to pop it after the
initialization code).
Also make sure we only call this operator delete along the path
where we actually allocated something.
Fixes rdar://problem/8439196.
llvm-svn: 114145
slot. The easiest way to do that was to bundle up the information
we care about for aggregate slots into a new structure which demands
that its creators at least consider the question.
I could probably be convinced that the ObjC 'needs GC' bit should
be rolled into this structure.
Implement generalized copy elision. The main obstacle here is that
IR-generation must be much more careful about making sure that exactly
llvm-svn: 113962
complains when the element type of a C++ "delete" expression is
different from what we would expect from the pointer type. When
deleting a bool*, we end up with an i1 on one side (where we compute
the LLVM type from the Clang bool type) and i8 on the other (where we
grab the LLVM type from the LLVM pointer type). I've weakened the
assertion appropriately, and the Boost Parallel Graph Library now
passes its regression tests.
llvm-svn: 112821
constructing an LLVM PointerType directly from the "bool"'s LLVM type
(i1), which resulted in unfortunate pointer type i1*. The fix is to
build the LLVM PointerType from the corresponding Clang PointerType,
so that we get i8* in the case of a bool.
John, please review. I also left a FIXME there because we seem to be
dropping "volatile", which would be rather unfortunate.
llvm-svn: 112819
implement ARM array cookies. Also fix a few unfortunate bugs:
- throwing dtors in deletes prevented the allocation from being deleted
- adding the cookie to the new[] size was not being considered for
overflow (and, more seriously, was screwing up the earlier checks)
- deleting an array via a pointer to array of class type was not
causing any destructors to be run and was passing the unadjusted
pointer to the deallocator
- lots of address-space problems, in case anyone wants to support
free store in a variant address space :)
llvm-svn: 112814
caused by my ABI work. Passing:
struct outer {
int x;
struct epsilon_matcher {} e;
int f;
};
as {i32,i32} isn't safe, because the offset of the second element
needs to be at 8 when it is interpreted as a memory value.
llvm-svn: 112686
templates when only the declaration is in scope. This requires deferring the
instantiation to be lazy, and ensuring the definition is required for that
translation unit. We re-use the existing pending instantiation queue,
previously only used to track implicit instantiations which were required to be
lazy. Fixes PR7979.
A subsequent change will rename *PendingImplicitInstantiations to
*PendingInstatiations for clarity given its broader role.
llvm-svn: 112037
but not in C++, so don't emit aggregate loads of volatile references
in null context in C++. Happens to have been caught by an assertion.
We do not get the scalar case right. Volatiles are really broken.
llvm-svn: 112019
That revision started classifying truly empty structs like "Y" and "X"
as being NoClass/NoClass and turning them into 'ignore'. The call code
turns around and allocates space for the ignored argument with
GetUndefRValue. The bug is that GetUndefRValue would return the address
as undef, instead of returning an object with a defined address but
undefined contents.
llvm-svn: 111794
class; they should just be completely opaque throughout IR gen now,
although I haven't really audited that.
Fix a bug apparently inherited from gcc-4.2 where we failed to null-check
member data pointers when performing derived-to-base or base-to-derived
conversions on them.
llvm-svn: 111789
implicitly-defined default constructor, zero-initialize the memory
before calling the default constructor. Previously, we would only
zero-initialize in the case of a trivial default constructor.
Also, simplify the hideous logic that determines when we have a
trivial default constructor and, therefore, don't need to emit any
call at all.
llvm-svn: 111779
pointers. I find the resulting code to be substantially cleaner, and it
makes it very easy to use the same APIs for data member pointers (which I have
conscientiously avoided here), and it avoids a plethora of potential
inefficiencies due to excessive memory copying, but we'll have to see if it
actually works.
llvm-svn: 111776
duplication between the constant and non-constant paths in all of this.
Implement ARM ABI semantics for member pointer constants and conversion.
llvm-svn: 111772
trivial default constructors. We're weren't zero-initializing them,
which manifested as <rdar://problem/8320532> (a regression in the GCC
test suite) and is likely to have caused significant other breakage.
llvm-svn: 111650
mangleCallExpression. Also, operator names with unknown arity should
be mangled as binary operators; this is actually covered by an oddly-
positioned sentence in the ABI document. Fixes PR7891.
llvm-svn: 111395
a -cc1 option. The Darwin linker complains about mixed visibility when linking
gcc-built objects with clang-built objects, and the optimization isn't really
that valuable. Platforms with less ornery linkers can feel free to enable this.
llvm-svn: 110979
to avoid the awesome-but-wrong-in-this-case assertion in the canon EAC.
Fixes PR7834.
Also fix a subtle address-space bug in the memset path.
llvm-svn: 110511
do the right thing with mixed-visibility symbols, so disable the visibility
optimization where that's possible, i.e. with template classes (since it's
possible that an arbitrary template might be subject to an explicit
instantiation elsewhere). 447.dealII actually does this.
I've put the code under an option that's currently not hooked up to anything.
llvm-svn: 110374
functions with in-line definitions, since such thunks will be emitted at any
use of the function.
Completes the feature work for rdar://problem/7523229.
llvm-svn: 110285
Apply hidden visibility to most RTTI; libstdc++ does not rely on exact
pointer equality for the type info (just the type info names). Apply
the same optimization to RTTI that we do to vtables.
Fixes PR5962.
llvm-svn: 110192
The X86-64 ABI code didn't handle the case when a struct
would get classified and turn up as "NoClass INTEGER" for
example. This is perfectly possible when the first slot
is all padding (e.g. due to empty base classes). In this
situation, the first 8-byte doesn't take a register at all,
only the second 8-byte does.
This fixes this by enhancing the x86-64 abi stuff to allow
and handle this case, reverts the broken fix for PR5831,
and enhances the target independent stuff to be able to
handle an argument value in registers being accessed at an
offset from the memory value.
This is the last x86-64 calling convention related miscompile
that I'm aware of.
llvm-svn: 109848
return where the struct has a base but no fields. This
was because the x86-64 abi logic was checking the wrong
predicate in one place.
This was introduced in r91874, which was a fix for PR5831,
which lacked a CHECK line, so I verified and added it.
llvm-svn: 109759
have a "coerce to" type which often matches the default lowering of Clang
type to LLVM IR type, but the coerce case can be handled by making them
not be the same.
This simplifies things and fixes issues where X86-64 abi lowering would
return coerce after making preferred types exactly match up. This caused
us to compile:
typedef float v4f32 __attribute__((__vector_size__(16)));
v4f32 foo(v4f32 X) {
return X+X;
}
into this code at -O0:
define <4 x float> @foo(<4 x float> %X.coerce) nounwind {
entry:
%retval = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2]
%coerce = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2]
%X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3]
store <4 x float> %X.coerce, <4 x float>* %coerce
%X = load <4 x float>* %coerce ; <<4 x float>> [#uses=1]
store <4 x float> %X, <4 x float>* %X.addr
%tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1]
store <4 x float> %add, <4 x float>* %retval
%0 = load <4 x float>* %retval ; <<4 x float>> [#uses=1]
ret <4 x float> %0
}
Now we get:
define <4 x float> @foo(<4 x float> %X) nounwind {
entry:
%X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3]
store <4 x float> %X, <4 x float>* %X.addr
%tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1]
%add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1]
ret <4 x float> %add
}
This implements rdar://8248065
llvm-svn: 109733
enclosing normal cleanup, not the top of the EH stack. I'm *really*
surprised this hasn't been causing more problems.
Fixes rdar://problem/8231514.
llvm-svn: 109569
when the RHS of the ||/&& is ever 0 or 1. This handles a variety of
creative idioms for "true" used in C programs and fixes many false
positives at the expense of a few false negatives. This fixes
rdar://8230351.
llvm-svn: 109314
initializer of (). Make sure to use a simple memset() when we can, or
fall back to generating a loop when a simple memset will not
suffice. Fixes <rdar://problem/8212208>, a regression due to my work
in r107857.
llvm-svn: 108977
which generates more efficient and more obviously conformant
code. We now test for overflow of the multiply then force
the result to -1 if so. On X86, this generates nice code
like this:
__Z4testl: ## @_Z4testl
## BB#0: ## %entry
subl $12, %esp
movl $4, %eax
mull 16(%esp)
testl %edx, %edx
movl $-1, %ecx
cmovel %eax, %ecx
movl %ecx, (%esp)
call __Znam
addl $12, %esp
ret
llvm-svn: 108927
causing clang to compile this code into something that correctly throws a
length error, fixing a potential integer overflow security attack:
void *test(long N) {
return new int[N];
}
int main() {
test(1L << 62);
}
We do this even when exceptions are disabled, because it is better for the
code to abort than for the attack to succeed.
This is heavily based on a patch that Fariborz wrote.
llvm-svn: 108915
that involve binding a reference to a pure rvalue temporary (e.g., not
a class temporary), by creating a new temporary and copying the result
there. Fixes PR6024.
llvm-svn: 108431
mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.
Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this; for now we have some awkward code
duplication.
Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.
llvm-svn: 108270
t2.c:2:12: warning: use of logical && with constant operand; switch to bitwise &
or remove constant [-Wlogical-bitwise-confusion]
return x && 4;
^ ~
wording improvement suggestions are welcome.
llvm-svn: 108260
at -O0. The only change from the previous patch is that we don't try
to generate virtual method thunks for an available_externally
function.
llvm-svn: 108230
-O0, since we won't be using the definitions for anything anyway. For
lib/System/Path.o when built in Debug+Asserts mode, this leads to a 4%
improvement in compile time (and suppresses 440 function bodies).
<rdar://problem/7987644>
llvm-svn: 108156
CXXConstructExpr/CXXTemporaryObjectExpr/CXXNewExpr as
appropriate. Fixes PR7556, and provides a slide codegen improvement
when copy-initializing a POD class type from a value-initialized
temporary. Previously, we weren't eliding the copy.
llvm-svn: 107827
self-host. Hopefully these results hold up on different platforms.
I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions. Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.
Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former. Remove the need to track which cleanup scope a block is associated
with.
Document a lot of previously poorly-understood (by me, at least) behavior.
The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work. Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however. The HH is an unfortunate requirement of LLVM's EH IR.
llvm-svn: 107631
ObjC pointers were easy enough (as far as the ABI is concerned, they're
just pointers to structs), but I had to invent a new mangling for block
pointers. This is particularly worrying with the Microsoft ABI, because
it is a vendor-specific ABI; extending it could come back to bite us
later when MS extends it on their own (and you know they will).
llvm-svn: 107572
Only actual functions get mangled correctly; I don't know how to fix it for
function pointers yet. Thanks to John McCall for the hint.
Also, mangle anonymous tag types. I don't have a suitable testcase yet; I have
a feeling that that's going to need support for static locals, and I haven't
figured out exactly how MSVC's scheme for mangling those works.
llvm-svn: 107561
aren't dropping all exception specifications on destructors, the
exception specifications on implicitly-declared destructors were
detected as being wrong (which they were).
Introduce logic to provide a proper exception-specification for
implicitly-declared destructors. This also fixes PR6972.
Note that the other implicitly-declared special member functions also
need to get exception-specifications. I'll deal with that in a
subsequent commit.
llvm-svn: 107385
r107173, "fix PR7519: after thrashing around and remembering how all this stuff"
r107216, "fix PR7523, which was caused by the ABI code calling ConvertType instead"
This includes a fix to make ConvertTypeForMem handle the "recursive" case, and call
it as such when lowering function types which have an indirect result.
llvm-svn: 107310
doesn't mangle array parameters right), but I think that should be fixed
in Sema (Doug, John, what do you think?).
Also, stub out the remaining mangleType() routines.
llvm-svn: 107264
would trigger an extra method call).
- While in the area, I also changed Clang to not emit an unnecessary load from
'x' in cases like 'y = (x = 1)'.
llvm-svn: 107210
load/store nonsense in the epilog. For example, for:
int foo(int X) {
int A[100];
return A[X];
}
we used to generate:
%arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i64 %idxprom ; <i32*> [#uses=1]
%tmp1 = load i32* %arrayidx ; <i32> [#uses=1]
store i32 %tmp1, i32* %retval
%0 = load i32* %retval ; <i32> [#uses=1]
ret i32 %0
}
which codegen'd to this code:
_foo: ## @foo
## BB#0: ## %entry
subq $408, %rsp ## imm = 0x198
movl %edi, 400(%rsp)
movl 400(%rsp), %edi
movslq %edi, %rax
movl (%rsp,%rax,4), %edi
movl %edi, 404(%rsp)
movl 404(%rsp), %eax
addq $408, %rsp ## imm = 0x198
ret
Now we generate:
%arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i64 %idxprom ; <i32*> [#uses=1]
%tmp1 = load i32* %arrayidx ; <i32> [#uses=1]
ret i32 %tmp1
}
and:
_foo: ## @foo
## BB#0: ## %entry
subq $408, %rsp ## imm = 0x198
movl %edi, 404(%rsp)
movl 404(%rsp), %edi
movslq %edi, %rax
movl (%rsp,%rax,4), %eax
addq $408, %rsp ## imm = 0x198
ret
This actually does matter, cutting out 2000 lines of IR from CGStmt.ll
for example.
Another interesting effect is that altivec.h functions which are dead
now get dce'd by the inliner. Hence all the changes to
builtins-ppc-altivec.c to ensure the calls aren't dead.
llvm-svn: 106970
objective-c++ class objects which have GC'able objc object
pointers and need to use ObjC's objc_memmove_collectable
API (radar 8070772).
llvm-svn: 106061
- Mangle qualifiers.
- Start mangling variables' types into the name. A variable declared with a
builtin type should now mangle properly.
llvm-svn: 105931
(but not their types; that's later).
NOTE: Right now, variables in the global namespace don't get mangled, even
though they're supposed to be. This is because the default mangler
implements the shouldMangleDeclName() method that tells clang not to mangle
them. This will be fixed in a later patch.
llvm-svn: 105805
John McCall