| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9631
llvm-svn: 237463
|
| |
|
|
|
|
| |
It broke clang stage2, at least tblgen.
llvm-svn: 237418
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Space on stack allocated for unused structures returned by functions was unused
even when it's lifetime didn't intersect with lifetime of any other objects that
could use the same space.
The test added also checks for named and auto objects. It seems to make sense
to have this all in one place.
Reviewers: aadg, rsmith, rjmccall, rnk
Reviewed By: rnk
Subscribers: asl, cfe-commits
Differential Revision: http://reviews.llvm.org/D9743
llvm-svn: 237385
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237368
|
| |
|
|
|
|
| |
This fixes PR23414 as well.
llvm-svn: 237348
|
| |
|
|
|
|
|
| |
details in http://reviews.llvm.org/D9483
goes with llvm checkin r237150
llvm-svn: 237151
|
| |
|
|
|
|
|
| |
MSVC 2015 changed behavior from 2013; it imports move assignment
operators.
llvm-svn: 236966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We didn't supporting taking the address of virtual member functions
which overrode a method in a virtual base. We simply need to encode the
virtual base index in the member pointer.
This fixes PR23452.
N.B. There is no data member pointer side to this change because taking
the address of a virtual bases' data member gives you a member pointer
whose type is derived from the virtual bases' type, not the most derived
type.
llvm-svn: 236962
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC 2015 renamed the symbol found by name lookup for 'std::terminate'
so we cannot rely on using '?terminate@@YAXXZ'. Furthermore, it seems
that 2015 will be the first release of MSVC which permits inlining a
function which is noexcept into a function which isn't. This is
implemented by creating a cleanup for the invoker which jumps to
__std_terminate. Clang's implementation of this aspect of the MSVC
scheme is slightly less efficient in this respect because we use a
catch handler configured as a catch-all handler instead.
llvm-svn: 236961
|
| |
|
|
|
|
|
|
| |
comdats"
It broke pecoff, at least i686-cygwin.
llvm-svn: 236937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functions with available_externally linkage will not be emitted to object
files (they will just be undefined symbols), so it does not make sense to
put them in comdats.
Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject
instead of the Decl, and uses that in several places that had the faulty
logic.
Differential Revision: http://reviews.llvm.org/D9580
llvm-svn: 236879
|
| |
|
|
|
|
|
| |
The thread_local variables need their own numbers, they can't share with
the other static local variables.
llvm-svn: 236774
|
| |
|
|
|
|
| |
REQUIRES:asserts. It relies on label names.
llvm-svn: 236709
|
| |
|
|
|
|
|
| |
Fix for codegen of static variables declared inside of captured statements. Captured statements are actually a transparent DeclContexts, so we have to skip them when trying to get a mangled name for statics.
Differential Revision: http://reviews.llvm.org/D9522
llvm-svn: 236701
|
| |
|
|
|
|
|
|
|
| |
The MSVC 2015 ABI utilizes a rather straightforward adaptation of the
algorithm found in the appendix of N2382. While we are here, implement
support for emitting cleanups if an exception is thrown while we are
intitializing a static local variable.
llvm-svn: 236697
|
| |
|
|
| |
llvm-svn: 236542
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I discovered a case where the old algorithm would crash. Instead of
trying to patch the algorithm, rewrite it. The new algorithm operates
in three phases:
1. Find all paths to the subobject with the vptr.
2. Remove paths which are subsets of other paths.
3. Select the best path where 'best' is defined as introducing the most
covariant overriders. If two paths introduce different overriders,
raise a diagnostic.
llvm-svn: 236444
|
| |
|
|
|
|
|
| |
This test verifies that we can detect when the inheritance paths are
ambiguous due to covariant thunks, ensuring we don't regress PR16759.
llvm-svn: 236381
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A class might contain multiple ways of getting to a vbase, some of which
are virtual and other non-virtual. It may be the case that a
non-virtual base contains an override of a method in a vbase. This
means that we must carefully pick between a set of nvbases to determine
which is the best.
As a consequence, the findPathForVPtr algorithm is considerably simpler.
llvm-svn: 236353
|
| |
|
|
|
|
| |
The bug was fixed by r235921.
llvm-svn: 236254
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There can be multiple virtual bases which are on the path to a vfptr
when one vbase virtually inherits from another. We should prefer the
most derived virtual base which covariantly overrides a method in the
vfptr class; if we do not lengthen the path this way, we will end up
with too few vftable entries.
This fixes PR21073.
llvm-svn: 236239
|
| |
|
|
| |
llvm-svn: 236194
|
| |
|
|
|
|
|
|
| |
targeting i686.
r236155 missed the suffix in "@llvm.memcpy.p0i8.p0i8.i32".
llvm-svn: 236184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Hexagon is being updated, but there is not enough to pass these tests.
These sections are now on top of Colin's list.
Test Plan: Ran changes on hexagon-build-03.
Reviewers: colinl, rfoos
Reviewed By: rfoos
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9356
llvm-svn: 236173
|
| |
|
|
| |
llvm-svn: 236155
|
| |
|
|
|
|
| |
emitted as a memcpy.
llvm-svn: 236142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and as artificial local variables in the debug info.
This is a follow-up to r236059. We can't get rid of the local variables
entirely because the gdb buildbot depends on them, but we can mark them
as artificial while still emitting the correct debug info. As I learned
from review comments other compilers also follow this model.
A paired commit in LLVM temporarily relaxes the debug info verifier to
not check the integrity of DW_OP_bit_pieces of artificial variables.
rdar://problem/20730771
llvm-svn: 236125
|
| |
|
|
|
|
|
|
|
|
| |
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
|
| |
|
|
|
|
| |
This reverts commit r236059 as it breaks the gdb buildbot.
llvm-svn: 236110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the debug info. This patch deletes a hack that emits the members
of local anonymous unions as local variables.
Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits
the 32-bit storage for the "local variable" c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
rdar://problem/20730771
llvm-svn: 236059
|
| |
|
|
| |
llvm-svn: 236043
|
| |
|
|
|
|
|
|
| |
conditions in the IRGen struct layout code.
rdar://20636558
llvm-svn: 235949
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was a bug in r218285 that prevented us from seeing subsequent
virtual bases in the class hierarchy, leading to crashes later.
Also add some comments to this function, now that we better understand
what it's trying to do.
Fixes PR21062 and PR21064.
llvm-svn: 235899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes rdar://20621065.
A more elegant fix would preclude this case by defining the
rules such that zero-size classes are always formally empty.
I believe the only extensions which create zero-size classes
right now are flexible arrays and zero-length arrays; it's
not abstractly unreasonable to say that those don't count
as members for the purposes of emptiness, just as zero-width
bitfields don't count. But that's an ABI-affecting change
and requires further discussion; in the meantime, let's not
assert / miscompile.
llvm-svn: 235815
|
| |
|
|
|
|
|
| |
Member pointers in the MS ABI have different alignment depending on
whether they were created on the stack or live in a record.
llvm-svn: 235681
|
| |
|
|
|
|
| |
Treat a VLA type like an incomplete array type.
llvm-svn: 235575
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Type backreferences for arguments use the DecayedType's original type.
Because of this, arguments with the same canonical type with the same
mangling would not backreference each other if one was a
ConstantArrayType while the other was an IncompleteArrayType. Solve
this by canonicalizing the ConstantArrayType to a suitable
IncompleteArrayType.
This fixes PR23325.
llvm-svn: 235572
|
| |
|
|
|
|
|
|
|
| |
These extra endcatch markers aren't helping identify regions to outline,
so let's get rid of them. LLVM outlines (more or less) from begincatch
to endcatch. Any unwind edge from an enclosed invoke is a transition to
a new exception handler, which has it's own outlining markers.
llvm-svn: 235562
|
| |
|
|
|
|
|
|
| |
This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.
llvm-svn: 235553
|
| |
|
|
|
|
|
|
|
|
|
| |
Otherwise -fno-omit-frame-pointer and other flags like it aren't
applied.
Basic idea taken from Gao's patch, thanks!
Differential Revision: http://reviews.llvm.org/D9203
llvm-svn: 235537
|
| |
|
|
|
|
|
|
|
|
| |
For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.
Differential Revision: http://reviews.llvm.org/D9182
llvm-svn: 235471
|
| |
|
|
|
|
|
| |
The type for abnormal_termination can't be an i1, it an i8.
Filter functions return 'LONG', not 'int'.
llvm-svn: 235161
|
| |
|
|
|
|
| |
(migration for recent LLVM change to textual IR for calls)
llvm-svn: 235147
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r234767, as it was breaking all ARM buildbots for two days and the
assert is not in the code, making it difficult to spot the error, which would keep the
bots red for a few more days. New errors were silently introduced because of this bug,
and we don't want this to escalate.
llvm-svn: 234983
|
| |
|
|
|
|
|
|
|
|
|
| |
Reverts the code changes from r234675 but keeps the test case.
We were already maintaining a DenseMap of globals with dynamic
initializers anyway.
Fixes the test case from PR23234.
llvm-svn: 234961
|
| |
|
|
|
|
|
| |
The frameescape intrinsic cannot be inlined, so I fixed the inliner in
r234937. This should address PR23216.
llvm-svn: 234942
|
| |
|
|
| |
llvm-svn: 234789
|
| |
|
|
| |
llvm-svn: 234787
|
| |
|
|
| |
llvm-svn: 234786
|