| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The implementation in libc++ takes O(1) compile time, ours was O(n).
llvm-svn: 368990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
| |
llvm-svn: 299083
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 284730
|
|
|
|
|
|
|
|
|
| |
With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's
easy to add correct lifetime.end marks into the right RunCleanupsScope.
Differential Revision: http://reviews.llvm.org/D20499
llvm-svn: 274385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
landing pads.
Previously, lifetime.end intrinsics were inserted only on normal control
flows. This prevented StackColoring from merging stack slots for objects
that were destroyed on the exception handling control flow since it
couldn't tell their lifetime ranges were disjoint. This patch fixes
code-gen to emit the intrinsic on both control flows.
rdar://problem/22181976
Differential Revision: http://reviews.llvm.org/D18196
llvm-svn: 265197
|
|
|
|
|
|
|
|
|
|
| |
Depends on D15139.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D15140
llvm-svn: 255423
|
|
|
|
| |
llvm-svn: 250418
|
|
|
|
|
|
|
| |
Cleanupendpad is a lot like catchendpad, so we can reuse the same
EHScopeStack type.
llvm-svn: 247349
|
|
|
|
|
|
| |
polymorphically
llvm-svn: 245378
|
|
|
|
| |
llvm-svn: 245368
|
|
|
|
|
|
| |
move constructed in ConditionalCleanup::restore
llvm-svn: 245367
|
|
|
|
|
|
|
|
|
|
| |
The new EH instructions make it possible for LLVM to generate .xdata
tables that the MSVC personality routines will be happy about. Because
this is experimental, hide it behind a -cc1 flag (-fnew-ms-eh).
Differential Revision: http://reviews.llvm.org/D11405
llvm-svn: 243767
|
|
|
|
|
|
|
|
|
| |
That platform has alignof(uint64_t) == 4, but, since LLVM_ALIGNAS(...)
cannot take anything but literal integers due to MSVC limitations, the
literal '8' used there didn't match. Switch ScopeStackAlignment to
just use 8, as well.
llvm-svn: 242578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some const-correctness changes snuck in here too, since they were in the
area of code I was modifying.
This seems to make Clang actually work without Bus Error on
32bit-sparc.
Follow-up patches will factor out a trailing-object helper class, to
make classes using the idiom of appending objects to other objects
easier to understand, and to ensure (with static_assert) that required
alignment guarantees continue to hold.
Differential Revision: http://reviews.llvm.org/D10272
llvm-svn: 242554
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
If the revert helps, I'll get a repro this Monday. Else I'll put the change
back in.
llvm-svn: 234700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.
llvm-svn: 234581
|
|
|
|
| |
llvm-svn: 232122
|
|
|
|
|
|
|
|
|
|
|
| |
This is complicated by the fact that we can't simply use side-effecting
calls in an argument list without losing all guarantees about the order
they're emitted. To keep things deterministic we use tuples and brace
initialization, which thankfully guarantees evaluation order.
No functionality change intended.
llvm-svn: 232121
|
|
|
|
| |
llvm-svn: 230459
|
|
|
|
| |
llvm-svn: 230199
|
|
|
|
| |
llvm-svn: 229329
|
|
|
|
| |
llvm-svn: 229327
|
|
|
|
|
|
|
|
|
|
| |
It says there is a narrowing conversion when we assign it to an unsigned
3 bit bitfield.
Also, use unsigned instead of size_t for the Size field of the struct in
question. Otherwise they won't run together in MSVC or clang-cl.
llvm-svn: 221019
|
|
|
|
|
|
| |
Modifications made by clang-tidy with minor tweaks.
llvm-svn: 215557
|
|
|
|
| |
llvm-svn: 209272
|
|
|
|
|
|
| |
class.
llvm-svn: 203643
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203241
|
|
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
|
CGCleanup.h isn't meant to be included by all of CodeGen according to
John.
llvm-svn: 184321
|