| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This reverts commit https://reviews.llvm.org/rL344150 which causes
MachineOutliner related failures on the ppc64le multistage buildbot.
llvm-svn: 344526
|
|
|
|
|
|
|
|
|
| |
This is currently a clang extension and a resolution
of the defect report in the C++ Standard.
Differential Revision: https://reviews.llvm.org/D46441
llvm-svn: 344150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
beyond value/repair
Several of these tests (the two deleted, and the one removal edit) were
relying on the optimizer to collapse things to test some frontend
feature. The tests were really old and features seemed amply covered by
other parts of the test suite, so I just removed them.
If anyone thinks they're valuable enough to keep/fix, we can play around
with that, for sure.
(inspired by r252872)
llvm-svn: 253114
|
|
|
|
|
|
| |
FunctionAttrs has just been taught how to infer 'norecurse'. Update clang tests for LLVM r252871.
llvm-svn: 252872
|
|
|
|
|
|
|
|
| |
The first named data member is the field used to default initialize the
union. An IndirectFieldDecl can introduce the first named data member
of a union.
llvm-svn: 238649
|
|
|
|
|
|
|
|
|
|
| |
Types can be classified as being zero-initializable or
non-zero-initializable. We used to classify array types by giving them
the classification of their base element type. However, incomplete
array types are never initialized directly and thus are always
zero-initializable.
llvm-svn: 238256
|
|
|
|
| |
llvm-svn: 230795
|
|
|
|
| |
llvm-svn: 230783
|
|
|
|
|
|
|
|
|
|
| |
Unions are initialized with the default initialization of their first
named member. If that member is not zero initialized, then we should
prefer that member's type. Otherwise, we might try to make an otherwise
unsuitable type (like an array) which we cannot easily initialize with a
pointer to member.
llvm-svn: 219781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang uses two types to talk about a C++ class, the
NonVirtualBaseLLVMType and the LLVMType. Previously, we would allow one
of these to be packed and the other not.
This is problematic. If both don't agree on a common subset of fields,
then routines like getLLVMFieldNo will point to the wrong field. Solve
this by copying the 'packed'-ness of the complete type to the
non-virtual subobject. For this to work, we need to take into account
the non-virtual subobject's size and alignment when we are computing the
layout of the complete object.
This fixes PR21089.
llvm-svn: 218577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 213386
|
|
|
|
|
|
| |
type in a function type where the C++ type is a reference. Update the tests.
llvm-svn: 209723
|
|
|
|
|
|
| |
tests fail.
llvm-svn: 188447
|
|
|
|
|
|
| |
These can be easily queried by the back-end.
llvm-svn: 176304
|
|
|
|
| |
llvm-svn: 176145
|
|
|
|
|
|
|
|
| |
This reverts commit 176009.
The commit is a likely cause of several buildbot failures.
llvm-svn: 176044
|
|
|
|
|
|
|
| |
This is an ongoing process. Any command line option which a back-end cares about
should be added here.
llvm-svn: 176009
|
|
|
|
|
|
| |
function attributes.
llvm-svn: 175606
|
|
|
|
|
|
| |
field has a non-trivial copy constructor. PR13097.
llvm-svn: 158578
|
|
|
|
|
|
| |
member as the first field. PR11487.
llvm-svn: 146009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
us to compile
stuff like this:
typedef struct {
int x, y, z;
} foo_t;
foo_t g;
into:
%"struct.<anonymous>" = type { i32, i32, i32 }
we now get:
%struct.foo_t = type { i32, i32, i32 }
This doesn't change the behavior of the compiler, but makes the IR much easier to read.
llvm-svn: 134969
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
turns out that a field or base needs to be laid out in the tail padding of
the base, CGRecordLayoutBuilder::ResizeLastBaseFieldIfNecessary will convert
it to an array of i8.
I've audited the new test results to make sure that they are still valid. I've
also verified that we pass a self-host with this change.
This (finally) fixes PR5589!
llvm-svn: 129673
|
|
|
|
|
|
|
|
|
|
|
|
| |
a zero constant for a complete class. rdar://problem/8424975
To make this happen, track the field indexes for virtual bases
in the complete object. I'm curious whether we might be better
off making CGRecordLayoutBuilder *much* more reliant on
ASTRecordLayout; we're currently duplicating an awful lot of the ABI
layout logic.
llvm-svn: 125555
|
|
|
|
| |
llvm-svn: 124210
|
|
|
|
| |
llvm-svn: 123197
|
|
|
|
|
|
| |
Fixes PR8507.
llvm-svn: 117850
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
While I'm in there, adjust pointer to member adjustments as well.
llvm-svn: 106955
|
|
|
|
| |
llvm-svn: 105391
|
|
|
|
|
|
| |
virtual bases. Just initialize them to null.
llvm-svn: 104868
|
|
|
|
|
|
| |
first fix broke self-host.
llvm-svn: 104447
|
|
|
|
| |
llvm-svn: 104446
|
|
|
|
| |
llvm-svn: 104390
|
|
|
|
|
|
| |
setting null data member pointers correctly. Fixes PR7139.
llvm-svn: 104387
|
|
|
|
|
|
| |
that test case is a bit weird and I'd like to investigate further before closing that bug.
llvm-svn: 104025
|
|
|
|
|
|
| |
correctly.
llvm-svn: 103771
|
|
|
|
| |
llvm-svn: 95374
|
|
|
|
| |
llvm-svn: 95066
|
|
|
|
|
|
| |
CGExprConstant. Fixes PR5674.
llvm-svn: 95063
|
|
|
|
| |
llvm-svn: 95061
|
|
llvm-svn: 95060
|