| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
on Darwin.
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=25486
llvm-svn: 252707
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Especially for structs, the SAI object of a base pointer does not
describe all the types that the user might expect when he loads from
that base pointer. While we will still cast integers and pointers we
will now reload the value with the correct type if floating point and
non-floating point values are involved. However, there are now TODOs
where we use bitcasts instead of a proper conversion or reloading.
This fixes bug 25479.
llvm-svn: 252706
|
| |
|
|
| |
llvm-svn: 252705
|
| |
|
|
| |
llvm-svn: 252704
|
| |
|
|
|
|
|
| |
We have several tests that TIMEOUT under heavy load but just need a bit
more time to complete.
llvm-svn: 252703
|
| |
|
|
|
|
|
|
|
|
| |
This test fails most of the time when run under heavy load. The dsym
variant doesn't seem to be failing.
Tracking XFAIL marker with:
https://llvm.org/bugs/show_bug.cgi?id=25485
llvm-svn: 252702
|
| |
|
|
|
|
|
|
|
|
|
| |
We now create all invariant equivalence classes for required invariant loads
instead of creating them on-demand. This way we can check if a parameter
references an invariant load that is actually not executed and was therefor
not materialized. If that happens the parameter is not materialized either.
This fixes bug 25469.
llvm-svn: 252701
|
| |
|
|
|
|
| |
robust against inputs that aren't already the right type.
llvm-svn: 252700
|
| |
|
|
|
|
|
| |
See the following tracking bug:
https://llvm.org/bugs/show_bug.cgi?id=25484
llvm-svn: 252699
|
| |
|
|
|
|
|
| |
I missed an earlier exit for the --succinct case when I introduced the
-a option.
llvm-svn: 252698
|
| |
|
|
|
|
| |
instead of the vector type. This matches gcc and removes extras casts.
llvm-svn: 252697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D9637
Test Plan:
Reviewers: kcc, glider, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9638
llvm-svn: 252696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On Darwin, interposed functions are prefixed with "wrap_". On Linux,
they are prefixed with "__interceptor_".
Reviewers: dvyukov, samsonov, glider, kcc, kubabrecka
Subscribers: zaks.anna, llvm-commits
Differential Revision: http://reviews.llvm.org/D14512
llvm-svn: 252695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer. Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.
This only works when the node *can* get access to the owning list. The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead. The requirements:
- `NodeTy` must have a `getParent()` function that returns the parent.
- `ParentTy` must have a `getSublistAccess()` static that, given a(n
ignored) `NodeTy*` (to determine which list), returns a member field
pointer to the appropriate `ilist<>`.
This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).
If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.
If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.
Why rewrite this?
The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all! The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).
There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`). I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
What's the danger?
There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`. I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two. I hope not.
(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)
llvm-svn: 252694
|
| |
|
|
|
|
| |
rdar://problem/19836465
llvm-svn: 252693
|
| |
|
|
|
|
|
|
|
| |
Sort the enums in preparation for moving the attributes to a table-gen
file.
rdar://problem/19836465
llvm-svn: 252692
|
| |
|
|
| |
llvm-svn: 252691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
|
| |
|
|
|
|
|
|
|
| |
It can't be built due to cxxabi missing. Will
fix later.
Differential Revision: http://reviews.llvm.org/D14559
llvm-svn: 252689
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
|
| |
|
|
| |
llvm-svn: 252687
|
| |
|
|
| |
llvm-svn: 252686
|
| |
|
|
| |
llvm-svn: 252685
|
| |
|
|
| |
llvm-svn: 252684
|
| |
|
|
|
|
|
|
|
|
| |
Summary:
First batch of sancov.py rewrite in C++.
Supports "-print" and "-covered_functions" commands.
Differential Revision: http://reviews.llvm.org/D14356
llvm-svn: 252683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
leaq symbol@tlsld(%rip), %rdi
call __tls_get_addr@plt
symbol@tlsld (R_X86_64_TLSLD) instructs the linker to generate a tls_index entry (two GOT slots) in the GOT for the entire module (shared object or executable) with an offset of 0. The symbol for this GOT entry doesn't matter (as long as it's either local to the module or null), and gold doesn't put a symbol in the dynamic R_X86_64_DTPMOD64 relocation for the GOT entry.
All other platforms defined in http://www.akkadia.org/drepper/tls.pdf except for Itanium use a similar model where global and local dynamic GOT entries take up 2 contiguous GOT slots, so we can handle this in a unified manner if we don't care about Itanium.
While scanning relocations we need to identify local dynamic relocations and generate a single tls_index entry in the GOT for the module and store the address of it somewhere so we can later statically resolve the offset for R_X86_64_TLSLD relocations. We also need to generate a R_X86_64_DTPMOD64 relocation in the RelaDyn relocation section.
This implementation is a bit hacky. It side steps the issue of GotSection and RelocationSection only handling SymbolBody entries by relying on a specific relocation type. The alternative to this seemed to be completely rewriting how GotSection and RelocationSection work, or using a different hacky signaling method.
llvm-svn: 252682
|
| |
|
|
|
|
|
| |
Follow-up to r235963: this matches other assemblers and is less
unexpected (e.g. PR23227).
llvm-svn: 252681
|
| |
|
|
|
|
| |
This is now allowed and has the behavior of removing the mapping.
llvm-svn: 252679
|
| |
|
|
|
|
| |
This way we can not only add but also remove read undef flags.
llvm-svn: 252678
|
| |
|
|
| |
llvm-svn: 252677
|
| |
|
|
|
|
|
|
| |
Right now isTruePredicate is only ever called with Pred == ICMP_SLE or
ICMP_ULE, and the ICMP_SLT and ICMP_ULT cases are dead. This change
removes the untested dead code so that the function is not misleading.
llvm-svn: 252676
|
| |
|
|
| |
llvm-svn: 252675
|
| |
|
|
| |
llvm-svn: 252674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change teaches isImpliedCondition to prove things like
(A | 15) < L ==> (A | 14) < L
if the low 4 bits of A are known to be zero.
Depends on D14391
Reviewers: majnemer, reames, hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14392
llvm-svn: 252673
|
| |
|
|
|
|
|
|
| |
This change would add functionality if isImpliedCondition worked on
vector types; but since it bail out on vector predicates this change is
an NFC.
llvm-svn: 252672
|
| |
|
|
|
|
|
| |
This makes it slightly easier to handle classes with and without
subregister uniformly.
llvm-svn: 252671
|
| |
|
|
|
|
|
| |
Inserting it before the target block could be bad, we might already have
a fallthrough edge to it.
llvm-svn: 252670
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move handling of the SONAME option from add_llvm_library
to llvm_add_library, so that it can be used in sub-projects.
In particular, this makes it possible to have consistently
named shared libraries for LLVM, Clang and LLDB.
Also, base the SONAME and symlinks on the output name
by extracting the OUTPUT_NAME property, rather than assuming
it is the same as the target name.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14539
llvm-svn: 252669
|
| |
|
|
|
|
| |
This was an accidental regression from the MRC __weak patch.
llvm-svn: 252668
|
| |
|
|
| |
llvm-svn: 252667
|
| |
|
|
| |
llvm-svn: 252666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It used to be a unique pointer, and there could be a case where ClangASTSource
held onto a copy of the pointer but Target::Destroy destroyed the unique pointer
in the mean time.
I also ensured that there is a validity check on the target (which confirms that
a ClangASTImporter can be generated) before the target's shared pointer is
copied into ClangASTSource.
This race condition caused a crash if Target::Destroy was called and then later
the target objecct was deleted.
llvm-svn: 252665
|
| |
|
|
| |
llvm-svn: 252664
|
| |
|
|
|
|
|
|
|
|
| |
are "nil" (not pointing to anything) or uninitialized (never made to point at anything)
This latter determination may or may not be possible on a per-language basis; and neither is mandatory to implement for any language
Use this knowledge in the ValueObjectPrinter to generalize the notion of IsObjCNil() and the respective printout
llvm-svn: 252663
|
| |
|
|
| |
llvm-svn: 252662
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14553
llvm-svn: 252661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds documentation on compiling CUDA with LLVM as requested by many
engineers and researchers. It includes not only user guides but also some
internals (mostly optimizations) so that early adopters can start hacking and
contributing.
Quite a few researchers who contacted us haven't used LLVM before, which is
unsurprising as it hasn't been long since LLVM picked up CUDA. So I added a
short summary to help these folks get started with LLVM.
I expect this document to evolve substantially down the road. The user guides
will be much simplified after the Clang integration is done. However, the
internals should continue growing to include for example performance debugging
and key areas to improve.
Reviewers: chandlerc, meheff, broune, tra
Subscribers: silvas, jingyue, llvm-commits, eliben
Differential Revision: http://reviews.llvm.org/D14370
llvm-svn: 252660
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comes up when a derived class destructor is equivalent to a base
class destructor defined in the same TU, and we try to alias them.
A COFF weak alias cannot satisfy a normal undefined symbol reference
from another TU. The other TU must also mark the referenced symbol as
weak, and we can't rely on that.
Clang already has a special case here for dllexport, but we failed to
realize that the problem also applies to other non-discardable symbols
such as those from explicit template instantiations.
Fixes PR25477.
llvm-svn: 252659
|
| |
|
|
| |
llvm-svn: 252658
|
| |
|
|
| |
llvm-svn: 252657
|