Change the interface to expose the new information and deal with the enormous fallout.
Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications.
Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127537 91177308-0d34-0410-b5e6-96231b3b80d8
allocation and therefore requires a null-check. We were doing that, but
we weren't treating the new-initializer as being conditionally executed,
which means it was possible to get ill-formed IR as in PR9298.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127147 91177308-0d34-0410-b5e6-96231b3b80d8
Block{Function,Module} base class. Minor other refactorings.
Fixed a few address-space bugs while I was there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125085 91177308-0d34-0410-b5e6-96231b3b80d8
fixing a crash which probably nobody was ever going to see. In doing so,
fix a horrendous number of problems with the conditional-cleanups code.
Also, make conditional cleanups re-use the cleanup's activation variable,
which avoids some unfortunate repetitiveness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124481 91177308-0d34-0410-b5e6-96231b3b80d8
deallocation function has a two-argument form. Store the result of this
check in new[] and delete[] nodes.
Fixes rdar://problem/8913519
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124373 91177308-0d34-0410-b5e6-96231b3b80d8
For example:
class A{
public:
A& operator=(const A& that) {
if (this != &that) {
this->A::~A();
this->A::A(that); // <=== explicit constructor call.
}
return *this;
}
};
More work will be needed to support an explicit call to a template constructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123735 91177308-0d34-0410-b5e6-96231b3b80d8
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121121 91177308-0d34-0410-b5e6-96231b3b80d8
objects imported into blocks. //rdar://8594790.
Will have a test case coming (as well as one
sent to llvm test suite).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120713 91177308-0d34-0410-b5e6-96231b3b80d8
copy helper function and dtor of copied cxx objects
in dispose helper functions. __block variables
TBD next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119011 91177308-0d34-0410-b5e6-96231b3b80d8
In this experimental mode try avoiding debug info emission for classes as much as possible. The goal is to reduce size of produced debuginfo without reducing quality of debug info in general. This is a work in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115188 91177308-0d34-0410-b5e6-96231b3b80d8
already be determined by isCopyAssignmentOperator(), and was set too
late in the process for all clients to see the appropriate
value. Cleanup only; no functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114916 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
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113962 91177308-0d34-0410-b5e6-96231b3b80d8
to set up a destructor call, because ABIs can tweak these conventions.
Fixes rdar://problem/8386802.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112821 91177308-0d34-0410-b5e6-96231b3b80d8
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 :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112814 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111779 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
update callers as best I can.
- This is a work in progress, our alignment handling is very horrible / sketchy -- I am just aiming for monotonic improvement.
- Serious review appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111707 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111650 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108977 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107827 91177308-0d34-0410-b5e6-96231b3b80d8
objective-c++ class objects which have GC'able objc object
pointers and need to use ObjC's objc_memmove_collectable
API (radar 8070772).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106061 91177308-0d34-0410-b5e6-96231b3b80d8
"return" statement and mark the corresponding CXXConstructExpr as
elidable. Teach CodeGen that eliding a temporary is different from
eliding an object construction.
This is just a baby step toward NRVO.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103849 91177308-0d34-0410-b5e6-96231b3b80d8
throw, it should use invoke when needed. The fixes the
Boost.Statechrt failures that motivated PR7132, but there are a few
side issues to tackle as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103803 91177308-0d34-0410-b5e6-96231b3b80d8
poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.
The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.
This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.
Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100196 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99920 91177308-0d34-0410-b5e6-96231b3b80d8
- This fixes many many more places than the test case, but my feeling is we need to audit alignment systematically so I'm not inclined to try hard to test the individual fixes in this patch. If this bothers you, patches welcome!
PR6240.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95648 91177308-0d34-0410-b5e6-96231b3b80d8
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95436 91177308-0d34-0410-b5e6-96231b3b80d8