copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289618 91177308-0d34-0410-b5e6-96231b3b80d8
The relative vtable ABI will use a struct rather than an array as the type
of a vtable. LLVM only allows 32-bit integers as struct indices, so we need
to use 32-bit integers to get addresses of address points. In order to keep
the code simple, we might as well do that unconditionally.
It's probably a reasonable implementation limit to support no more than 2
billion virtual functions per class.
This change causes quite a bit of churn in the test suite, so I'm making
it separately.
Differential Revision: http://reviews.llvm.org/D18113
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263469 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226751 91177308-0d34-0410-b5e6-96231b3b80d8
We currently use i32 (...)** as the type of the vptr field in the LLVM
struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of
the data being stored rather than on the pointer being stored to.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D5916
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223267 91177308-0d34-0410-b5e6-96231b3b80d8
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.
Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213386 91177308-0d34-0410-b5e6-96231b3b80d8
actually perform value initialization rather than trying to fake it with a call
to the default constructor. Fixes various bugs related to the previously-missing
zero-initialization in this case.
I've also moved this and the other list initialization 'special case' from
TryConstructorInitialization into TryListInitialization where they belong.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159733 91177308-0d34-0410-b5e6-96231b3b80d8
trivial if the implicit declaration would be. Don't forget to set the Trivial
flag on the special member as well as on the class. It doesn't seem ideal that
we have two separate mechanisms for storing this information, but this patch
does not attempt to address that.
This leaves us in an interesting position where the has_trivial_X trait for a
class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'.
This seems to be what the standard requires.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151465 91177308-0d34-0410-b5e6-96231b3b80d8
trivial default constructors. This generated-code regression was
caused by r131796, which had simplified the handling of default
initialization in Sema. Fixes <rdar://problem/9694300>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134260 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114153 91177308-0d34-0410-b5e6-96231b3b80d8
through the bases and fields of the definition of the class in which
the constructor is declared, rather than some other declaration of
that class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99661 91177308-0d34-0410-b5e6-96231b3b80d8
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization).
Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91750 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith