Age | Commit message (Collapse) | Author |
|
a EH-only cleanup as part of a fallthrough branch-through. That this happens
for this test case is actually a separate bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115668 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for the same destination, then we must potentially rewrite the initial branch
of every fixup. Without this patch, a short-circuit check meant to prevent
a switch case from being redundantly added was preventing later fixups from
being processed. Fixes PR8175 (again).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vla. Implements pr7827.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114737 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it reached the outermost scope and it hasn't yet been forwarded
to a cleanup. Fixed PR8175.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(but not if destructors associated with the full-expression throw).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
under the ARM ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112588 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to the new constants.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112047 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Make CGT defer to the ABI on all member pointer types.
This requires giving CGT a handle to the ABI.
It's way easier to make that work if we avoid lazily creating the ABI.
Make it so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111070 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Not yet complete or used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
treats that as a contract to be fulfilled by any replacements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
types. Fixes PR7865.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constant integer globals, based on Chris's feedback.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110694 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constant variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110511 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mark it nounwind based on whether it contains any non-nounwind calls.
<rdar://problem/8087431>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I knew this code duplication would bite me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109463 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
since we aren't going to be calling them ever.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109377 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as well as some significant asymptotic inefficiencies with threading
multiple jumps through deep cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109274 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
#line 41 "bar.c"
dummy (1, i);
#line 24 "bar.h"
i = f2 (i);
#line 44 "bar.c"
This is tested by step-line.exp in gdb testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
commits.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108946 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108927 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108270 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
emit metadata associating allocas and global values with a Decl*. This feature
is controlled by an option that (intentionally) cannot be enabled on the command
line.
To use this feature, simply set
CodeGenOptions.EmitDeclMetadata = true;
and then interpret the completely underspecified metadata. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
block before deleting it. Fixes PR7575.
This really just a short-term fix before implementing lazy cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
scope hasn't been set up yet so this isn't valid. It was just a cleanup to the
IR, so I'm going to ignore it for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107356 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107320 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
have CGF create and make accessible standard int32,int64 and
intptr types. This fixes a ton of 80 column violations
introduced by LLVMContextification and cleans up stuff a lot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106970 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106618 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Elhage!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
UniqueAggreDestructorCount from CodeGenFunction and let LLVM handle uniquing the internal functions instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105648 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variables within blocks. We loosely follow GCC's mangling, but since
these are always internal symbols the names don't really matter. I
intend to revisit block mangling later, because GCC's mangling is
rather verbose. <rdar://problem/8015719>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104390 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
setting null data member pointers correctly. Fixes PR7139.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104387 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assignment operators.
Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.
This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:
- For a class subobject, call the appropriate copy-assignment
operator, after overload resolution has determined what that is.
- For an array of scalar types or an array of class types that have
trivial copy assignment operators, construct a call to
__builtin_memcpy.
- For an array of class types with non-trivial copy assignment
operators, synthesize a (possibly nested!) for loop whose inner
statement calls the copy constructor.
- For a scalar type, use built-in assignment.
This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.
Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102853 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101100 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
field to memcpy, memmove, and memset.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100200 91177308-0d34-0410-b5e6-96231b3b80d8
|