| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Zachary introduced the 'default' case explicitly to placate a warning in
the Microsoft compiler but that broke clang with -Werror.
The new code should keep both compilers happy.
llvm-svn: 258212
|
|
|
|
|
|
|
|
|
| |
Summary: Extracting GetRangeOffset function before report-on-dump
functionality.
Differential Revision: http://reviews.llvm.org/D16332
llvm-svn: 258211
|
|
|
|
|
|
|
|
|
| |
I think I fixed all instances of this in the codebase
(r258202, 258200, 258190). Also, the suppression didn't
have an effect on bots using make anyways, and it looks
like many bots still use configure/make bots.
llvm-svn: 258210
|
|
|
|
|
|
|
|
|
|
| |
generate install actions and targets.
This change brings forward the LLVM convention that "executables" are just runnable binaries, and "tools" are executables that are part of the project's install.
Having this abstraction will allow us to simplify some of the tool CMakeLists files, and it will standardize some of the install behaviors.
llvm-svn: 258209
|
|
|
|
|
|
|
| |
Fully qualify reference to Finalized in the body of the lambda instead to work
around GCC ICE.
llvm-svn: 258208
|
|
|
|
| |
llvm-svn: 258207
|
|
|
|
| |
llvm-svn: 258206
|
|
|
|
|
|
|
|
|
|
| |
As vector shuffles can only reference two inputs many (V)INSERTPS patterns end up being split over two targets shuffles.
This patch adds combines to attempt to combine (V)INSERTPS nodes with input/output nodes that are just zeroing out these additional vector elements.
Differential Revision: http://reviews.llvm.org/D16072
llvm-svn: 258205
|
|
|
|
|
|
| |
This should fix some of the bot failures associated with r258185.
llvm-svn: 258204
|
|
|
|
|
|
|
|
| |
Suggested by Philip Reames in review of r257951.
Thanks Philip!
llvm-svn: 258203
|
|
|
|
| |
llvm-svn: 258202
|
|
|
|
| |
llvm-svn: 258201
|
|
|
|
| |
llvm-svn: 258200
|
|
|
|
| |
llvm-svn: 258199
|
|
|
|
| |
llvm-svn: 258198
|
|
|
|
|
|
|
|
|
| |
This pass currently emits an objc image info section if one is required.
This section contains the aggregated version and flags for all of the input
files.
llvm-svn: 258197
|
|
|
|
| |
llvm-svn: 258196
|
|
|
|
| |
llvm-svn: 258195
|
|
|
|
|
|
|
|
|
| |
A few files were accidentally added to the Copy Files build phase for our man
page, and they would appear when 'xcodebuild install' was invoked. This removes
those files – they continue to be built correctly, but they aren't installed
with our man page.
llvm-svn: 258194
|
|
|
|
| |
llvm-svn: 258193
|
|
|
|
| |
llvm-svn: 258192
|
|
|
|
| |
llvm-svn: 258191
|
|
|
|
|
|
|
|
|
| |
r100895 landed an llvm-only change to add minix support to googletest.
It did that by putting "defined()" in a macro, which has undefined
behavior. Slightly reshuffle things to remove that undefined behavior.
Also mention in README.LLVM that minix support is a local change.
llvm-svn: 258190
|
|
|
|
|
|
| |
Thanks to Rui for the suggestion.
llvm-svn: 258189
|
|
|
|
|
|
|
|
|
| |
function record pointer is not advanced when
duplicate entry is found.
Test case to be added.
llvm-svn: 258188
|
|
|
|
| |
llvm-svn: 258187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
they're needed.
Prior to this patch objects were loaded (via RuntimeDyld::loadObject) when they
were added to the ObjectLinkingLayer, but were not relocated and finalized until
a symbol address was requested. In the interim, another object could be loaded
and finalized with the same memory manager, causing relocation/finalization of
the first object to fail (as the first finalization call may have marked the
allocated memory for the first object read-only).
By deferring the loadObject call (and subsequent memory allocations) until an
object file is needed we can avoid prematurely finalizing memory.
llvm-svn: 258185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the max backedge taken count can be more conservative
than the exact backedge taken count (for instance, because
ScalarEvolution::getRange is not control-flow sensitive whereas
computeExitLimitFromICmp can be). In these cases,
computeExitLimitFromCond (specifically the bit that deals with `and` and
`or` instructions) can create an ExitLimit instance with a
`SCEVCouldNotCompute` max backedge count expression, but a computable
exact backedge count expression. This violates an implicit SCEV
assumption: a computable exact BE count should imply a computable max BE
count.
This change
- Makes the above implicit invariant explicit by adding an assert to
ExitLimit's constructor
- Changes `computeExitLimitFromCond` to be more robust around
conservative max backedge counts
llvm-svn: 258184
|
|
|
|
| |
llvm-svn: 258183
|
|
|
|
|
|
|
| |
The following test program triggers the assertion:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.c-torture/execute/20030916-1.c
llvm-svn: 258182
|
|
|
|
| |
llvm-svn: 258181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enter/exit data directives.
Support for the following OpenMP 4.5 restriction on 'target enter data' and 'target exit data':
- A map-type must be specified in all map clauses.
I have to save 'IsMapTypeImplicit' when parsing a map clause to support this constraint and for more informative error messages. This helps me support the following case:
#pragma omp target enter data map(r) // expected-error {{map type must be specified for '#pragma omp target enter data'}}
and distinguish it from:
#pragma omp target enter data map(tofrom: r) // expected-error {{map type 'tofrom' is not allowed for '#pragma omp target enter data'}}
Patch by Arpith Jacob. Thanks!
llvm-svn: 258179
|
|
|
|
|
|
| |
MyStoll to handle negative values. Use std::any_of instead of std::find_if
llvm-svn: 258178
|
|
|
|
|
|
| |
Patch by Arpith Jacob. Thanks!
llvm-svn: 258177
|
|
|
|
| |
llvm-svn: 258176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we'd crash the driver if you passed -O0. Now we try to
handle all of clang's various optimization flags in a sane way.
Reviewers: tra
Subscribers: cfe-commits, echristo, jhen
Differential Revision: http://reviews.llvm.org/D16307
llvm-svn: 258174
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like arch, os, etc, when we know we are going to use a file, we check
that the file has compatible objc constraints to the context, throw
appropriate errors where that is not the case, and hopefully set the
objc constraints on the context for use later.
Added 2 tests to ensure that we don't have incompatibilities between
host and simulator code as both will get x86 based architectures.
llvm-svn: 258173
|
|
|
|
|
|
|
|
| |
Note: There are no uses of these functions outside of
SimplifyLibCalls, so they could be static functions in
that file.
llvm-svn: 258172
|
|
|
|
|
|
|
| |
Newly-built Clangs don't automatically find the SDK, and newer versions
of Mac OS X don't provide it under /usr/include etc.
llvm-svn: 258169
|
|
|
|
|
|
| |
This didn't work for 3.7, but hopefully it should work now.
llvm-svn: 258168
|
|
|
|
| |
llvm-svn: 258167
|
|
|
|
| |
llvm-svn: 258166
|
|
|
|
|
|
| |
Patch by Arpith Jacob. Thanks!
llvm-svn: 258165
|
|
|
|
| |
llvm-svn: 258164
|
|
|
|
| |
llvm-svn: 258163
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16297
llvm-svn: 258161
|
|
|
|
|
|
|
|
|
|
| |
Image info flags describe the objc constraint which is GC/retain/release/etc.
These need to be parsed and stored in the file so that we can do error checking.
That will come in a later commit.
llvm-svn: 258160
|
|
|
|
|
|
| |
According the build bots, clang is using the Registry class somewhere as well. Will reapply with appropriate clang changes at a later point.
llvm-svn: 258159
|
|
|
|
|
|
|
| |
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
llvm-svn: 258158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Registry class constructs a linked list of nodes whose storage is inside static variables and nodes are added via static initializers. The trick is that those static initializers are in both the LLVM code base, and some random plugin that might get loaded in at runtime. The existing code tries to use C++ templates and their ODR rules to get a single definition of the registry for each type, but, experimentally, this doesn't quite work as designed. (Well, the entire structure doesn't. It might not actually be an ODR problem.)
Previously, when I tried moving the GCStrategy class (along with it's registry) from CodeGen to IR, I ran into a problem where asking the GCStrategyRegistry a question would return inconsistent results depending on whether you asked from CodeGen (where the static initializers still were) or Transforms. My best guess is that this is a result of either a) an order of initialization error, or b) we ended up with two copies of the registry being created. I remember at the time having convinced myself it was probably (b), but I don't have any of my notes around from that investigation any more.
See http://reviews.llvm.org/rL226311 for the original patch in question.
This patch tries to remove the possibility of (b) above. (a) was already fixed in change 258109.
Differential Revision: http://reviews.llvm.org/D16170
llvm-svn: 258157
|