| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This is the first step in making ELF2 the default.
llvm-svn: 253188
|
|
|
|
|
|
|
| |
Referencing a DILocation whose scope is a different subprogram causes
an assertion failure.
llvm-svn: 253187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Since we're passing references to dbg.value as pointers,
we need to have the frontend properly declare their sizes and
alignments (as it already does for regular pointers) in preparation
for my upcoming patch to have the verifer check that the sizes agree.
Also augment the backend logic that skips actually emitting this
information into DWARF such that it also handles reference types.
Reviewers: aprantl, dexonsmith, dblaikie
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14275
llvm-svn: 253186
|
|
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14322
llvm-svn: 253185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_empty, is_polymorphic, and is_abstract didn't handle incomplete types
correctly. Only non-union class types must be complete for these
traits.
is_final and is_sealed don't care about the particular spelling of the
FinalAttr.
is_interface_class should always return false regardless of its input.
The type trait can only be satisfied in a mode we do not support (/CLR).
llvm-svn: 253184
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The Old personality function gets copied over, but the
Materializer didn't have a chance to inspect it (e.g. to fix up
references to the correct module for the target function).
Also add a verifier check that makes sure the personality routine
is in the same module as the function whose personality it is.
Reviewers: majnemer
Subscribers: jevinskie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14474
llvm-svn: 253183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Moving landingpads into successor basic blocks makes the
verifier sad. Teach Sink that much like PHI nodes and terminator
instructions, landingpads (and cleanuppads, etc.) may not be moved
between basic blocks.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14475
llvm-svn: 253182
|
|
|
|
| |
llvm-svn: 253181
|
|
|
|
|
|
|
| |
This makes it a bit easier to replace instances of vector<bool> with
BitVector.
llvm-svn: 253180
|
|
|
|
| |
llvm-svn: 253178
|
|
|
|
| |
llvm-svn: 253177
|
|
|
|
|
|
|
|
|
|
| |
When calling a ObjC method on super from inside a C++ lambda, look at the
captures to find "self". This mirrors how the analyzer handles calling super in
an ObjC block and fixes an assertion failure.
rdar://problem/23550077
llvm-svn: 253176
|
|
|
|
|
|
| |
on the AST context instead of Preprocessor. NFC
llvm-svn: 253175
|
|
|
|
| |
llvm-svn: 253174
|
|
|
|
| |
llvm-svn: 253173
|
|
|
|
|
|
| |
This seems to be the most popular convention among the other backends.
llvm-svn: 253172
|
|
|
|
| |
llvm-svn: 253171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch to move metadata linking after global value linking didn't
correctly map unmaterialized global values to null as desired. They
were in fact mapped to the source copy. It largely worked by accident
since most module linker clients destroyed the source module which
caused the source GVs to be replaced by null, but caused a failure with
LTO linking on Windows:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312869.html
The problem is that a null return value from materializeValueFor is
handled by mapping the value to self. This is the desired behavior when
materializeValueFor is passed a non-GlobalValue. The problem is how to
distinguish that case from the case where we really do want to map to
null.
This patch addresses this by passing in a new flag to the value mapper
indicating that unmapped global values should be mapped to null. Other
Value types are handled as before.
Note that the documented behavior of asserting on unmapped values when
the flag RF_IgnoreMissingValues isn't set is currently disabled with
FIXME notes due to bootstrap failures. I modified these disabled asserts
so when they are eventually enabled again it won't assert for the
unmapped values when the new RF_NullMapMissingGlobalValues flag is set.
I also considered using a callback into the value materializer, but a
flag seemed cleaner given that there are already existing flags.
I also considered modifying materializeValueFor to return the input
value when we want to map to source and then treat a null return
to mean map to null. However, there are other value materializer
subclasses that implement materializeValueFor, and they would all need
to be audited and the return values possibly changed, which seemed
error-prone.
Reviewers: dexonsmith, joker.eph
Subscribers: pcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D14682
llvm-svn: 253170
|
|
|
|
|
|
| |
cvt intrinsics
llvm-svn: 253169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Global to local demotion can speed up programs that use globals a lot. It is particularly useful with LTO, when the entire call graph is known and most functions have been internalized.
For a global to be demoted, it must only be accessed by one function and that function:
1. Must never recurse directly or indirectly, else the GV would be clobbered.
2. Must never rely on the value in GV at the start of the function (apart from the initializer).
GlobalOpt can already do this, but it is hamstrung and only ever tries to demote globals inside "main", because C++ gives extra guarantees about how main is called - once and only once.
In LTO mode, we can often prove the first property (if the function is internal by this point, we know enough about the callgraph to determine if it could possibly recurse). FunctionAttrs now infers the "norecurse" attribute for this reason.
The second property can be proven for a subset of functions by proving that all loads from GV are dominated by a store to GV. This is conservative in the name of compile time - this only requires a DominatorTree which is fairly cheap in the grand scheme of things. We could do more fancy stuff with MemoryDependenceAnalysis too to catch more cases but this appears to catch most of the useful ones in my testing.
llvm-svn: 253168
|
|
|
|
| |
llvm-svn: 253167
|
|
|
|
|
|
|
|
| |
This makes TypeAliasTemplateDecl accessible via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13844
llvm-svn: 253166
|
|
|
|
|
|
|
|
| |
Expose the AutoType via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13000
llvm-svn: 253165
|
|
|
|
| |
llvm-svn: 253164
|
|
|
|
|
|
| |
It broke layering violation. Reproducible with BUILD_SHARED_LIBS=ON.
llvm-svn: 253163
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of GEP visitor in InstCombine fails with assertion on Vector GEP with mix of scalar and vector types, like this:
getelementptr double, double* %a, <8 x i32> %i
(It fails to create a "sext" from <8 x i32> to <8 x i64>)
I fixed it and added some tests.
Differential Revision: http://reviews.llvm.org/D14485
llvm-svn: 253162
|
|
|
|
|
|
| |
Post-commit suggestion by Filipe Cabecinhas.
llvm-svn: 253161
|
|
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14322
llvm-svn: 253160
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Document the differences between the isKnownWindowsMSVC() and isWindowsMSVC() methods on Triple.
Also removed the '\brief' Doxygen annotations - now that 'AUTOBRIEF' is set to on, they are unnecessary.
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff
Differential Revision: http://reviews.llvm.org/D14110
llvm-svn: 253159
|
|
|
|
|
|
| |
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema.
llvm-svn: 253158
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer incorrectly treats captures as references if either the original
captured variable is a reference or the variable is captured by reference.
This causes the analyzer to crash when capturing a reference type by copy
(PR24914). Fix this by refering solely to the capture field to determine when a
DeclRefExpr for a lambda capture should be treated as a reference type.
https://llvm.org/bugs/show_bug.cgi?id=24914
rdar://problem/23524412
llvm-svn: 253157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
|
|
|
|
| |
llvm-svn: 253155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are currently two blocks with the METADATA_BLOCK id at module
scope. The first has the module-level metadata values (consisting of
some combination of METADATA_* record codes except for METADATA_KIND).
The second consists only of METADATA_KIND records. The latter is used
only in the METADATA_ATTACHMENT block within function blocks (for
metadata attached to instructions).
For ThinLTO we want to delay the parsing of module level metadata
until all functions have been imported from that module (there is some
bookkeeping used to suture it up when we read it during a post-pass).
However, we do need the METADATA_KIND records when parsing the function
body during importing, since those kinds are used as described above.
To simplify identification and parsing of just the block containing
the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID).
Support older bitcode without the new block id as well.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14654
llvm-svn: 253154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This diff approaches building the project natively on NetBSD with the autoconf/gmake framework.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: tberghammer, joerg, brucem, lldb-commits
Differential Revision: http://reviews.llvm.org/D14531
llvm-svn: 253153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: pkgsrc (on NetBSD) ships with python2.7-config.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14528
llvm-svn: 253152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This approach is tunable with custom paths for curses library.
It also detects whether there are requirements met.
I make use of it on NetBSD.
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14529
llvm-svn: 253151
|
|
|
|
| |
llvm-svn: 253150
|
|
|
|
| |
llvm-svn: 253149
|
|
|
|
| |
llvm-svn: 253148
|
|
|
|
| |
llvm-svn: 253147
|
|
|
|
| |
llvm-svn: 253146
|
|
|
|
|
|
|
|
|
|
| |
PT_GNU_STACK is a entry in the elf file format which contains the access rights (read, write, execute) of the stack,
it is always generated now. By default stack is not executable in this implementation.
-z execstack can be used to make executable.
Differential revision: http://reviews.llvm.org/D14571
llvm-svn: 253145
|
|
|
|
|
|
| |
Tidyup before diffs from new patch.
llvm-svn: 253144
|
|
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
|
|
|
| |
llvm-svn: 253142
|
|
|
|
| |
llvm-svn: 253141
|
|
|
|
|
|
| |
This removes a lot of code, which is A Good Thing(TM)
llvm-svn: 253140
|
|
|
|
| |
llvm-svn: 253139
|
|
|
|
| |
llvm-svn: 253138
|