llvm-svn: 286710

Summary: VALIGND and VALIGNQ are similar to PALIGNR but instead of working on a 128-bit lane they work on the entire vector register. This change leverages the shuffle rotate detection code used for PALIGNR to detect these cases.

Reviewers: delena, RKSimon

Subscribers: Farhana, llvm-commits

Differential Revision: https://reviews.llvm.org/D26297

llvm-svn: 286709

Summary:
In non-strict mode we will check memory access for both strings from beginning
to either:
  1. 0-char
  2. size
  3. different chars

In strict mode we will check from beginning to either:
  1. 0-char
  2. size

Previously in strict mode we always checked up to the 0-char.

Reviewers: kcc, eugenis

Subscribers: llvm-commits, kubabrecka

Differential Revision: https://reviews.llvm.org/D26574

llvm-svn: 286708

Since we now have tests for llvm-strings, add a dependency on the tool.

llvm-svn: 286707

We would ignore the last string that appeared if the file ended with a printable
character.  Ensure that we get the last string.

llvm-svn: 286706

llvm-svn: 286705

llvm-svn: 286704

llvm-svn: 286703

llvm-svn: 286702

return types.

This class allows user provided handlers to return either error-wrapped types
or plain types. In the latter case, the plain type is wrapped with a success
value of Error or Expected<T> type to fit it into the rest of the serialization
machinery.

This patch allows us to remove the RPC unit-test workaround added in r286646.

llvm-svn: 286701

ARC is 'Automatic Reference Counting' and not 'Automated Reference Counting'.

llvm-svn: 286700

llvm-svn: 286699

llvm-svn: 286698

The name of the NullableReturnedFromNonnullChecker in Checkers.td
was accidentally "NullablePassedToNonnull", which made it impossible
to explicitly turn the checker on.

rdar://problem/28354459

llvm-svn: 286697

llvm-svn: 286696

Differential Revision: https://reviews.llvm.org/D26565

llvm-svn: 286695

Under automated reference counting the analyzer treats a methods -- even those
starting with  'copy' and friends -- as returning an unowned value. This is
because ownership of CoreFoundation objects must be transferred to ARC
with __bridge_transfer or CFBridgingRelease() before being returned as
ARC-managed bridged objects.

Unfortunately this could lead to a poor diagnostic inside copy methods under
ARC where the analyzer would complain about a leak of a returned CF value inside
a method "whose name does not start with 'copy'" -- even though the name did
start with 'copy'.

This commit improves the diagnostic under ARC to say inside a method "returned
from a method managed by Automated Reference Counting".

rdar://problem/28849667

llvm-svn: 286694

Differential Revision: https://reviews.llvm.org/D26228

llvm-svn: 286693

llvm-svn: 286692

llvm-svn: 286691

llvm-svn: 286690

llvm-svn: 286689

llvm-svn: 286688

Summary: This fixes a regression caused by r286464.

Reviewers: arsenm

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, llvm-commits, tony-tye

Differential Revision: https://reviews.llvm.org/D26570

llvm-svn: 286687

llvm-svn: 286686

llvm-svn: 286685

Differential Revision: https://reviews.llvm.org/D26211

llvm-svn: 286684

llvm-svn: 286683

This introduces a new type-safe general purpose formatting
library.  It provides compile-time type safety, does not require
a format specifier (since the type is deduced), and provides
mechanisms for extending the format capability to user defined
types, and overriding the formatting behavior for existing types.

This patch additionally adds documentation for the API to the
LLVM programmer's manual.

Mailing List Thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105836.html

Differential Revision: https://reviews.llvm.org/D25587

llvm-svn: 286682

llvm-svn: 286681

This better reflects what it represents.

llvm-svn: 286680

llvm-svn: 286679

support constexpr char_traits.

llvm-svn: 286678

This patch defines a new function to add a SectionContribs stream
to a PDB file. Unlike SectionMap, SectionContribs contains a list
of input sections as opposed to output sections.

Note that this patch needs improving because currently we do not
set Module field in SectionContribs entries. In a follow-up patch,
I'll add Modules and then fix it after that.

Differential Revision: https://reviews.llvm.org/D26210

llvm-svn: 286677

Summary:
This pass was assuming that when a PHI instruction defined a register
used by another PHI instruction that the defining insstruction would
be legalized before the using instruction.

This assumption was causing the pass to not legalize some PHI nodes
within divergent flow-control.

This fixes a bug that was uncovered by r285762.

Reviewers: nhaehnle, arsenm

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, tony-tye, llvm-commits

Differential Revision: https://reviews.llvm.org/D26303

llvm-svn: 286676

When providing the project directory to the merge script, print it out in the
commit instructions instead of the default project directory.

llvm-svn: 286675

llvm-svn: 286674

llvm-svn: 286673

This introduces a function annotation that disables TSan checking for the
function at run time. The benefit over attribute((no_sanitize("thread")))
is that the accesses within the callees will also be suppressed.

The motivation for this attribute is a guarantee given by the objective C
language that the calls to the reference count decrement and object
deallocation will be synchronized. To model this properly, we would need to
intercept all ref count decrement calls (which are very common in ObjC due
to use of ARC) and also every single message send. Instead, we propose to
just ignore all accesses made from within dealloc at run time. The main
downside is that this still does not introduce any synchronization, which
means we might still report false positives if the code that relies on this
synchronization is not executed from within dealloc. However, we have not
seen this in practice so far and think these cases will be very rare.

(This problem is similar in nature to https://reviews.llvm.org/D21609;
unfortunately, the same solution does not apply here.)

Differential Revision: https://reviews.llvm.org/D25857

llvm-svn: 286672

Follow-up to r286664 cleanup as suggested by Eli. Thanks!

llvm-svn: 286671