Occasionally DAGCombiner can spot that a SETCC operation is completely
redundant and reduce it to "all true" or "all false". If this happens to a
vector, the value produced has to take account of what a normal comparison
would have produced, which may be an all-1s bitmask.

The fix in SelectionDAG.cpp is tested, however, as far as I can see the code in
TargetLowering.cpp is possibly unreachable and almost certainly irrelevant when
triggered so there are no tests. However, I believe it's still clearly the
right change and may save someone else some hassle if it suddenly becomes
reachable. So I'm doing it anyway.

llvm-svn: 190147

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190146

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190145

llvm-svn: 190144

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190143

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190142

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190141

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190140

llvm-svn: 190139

The architecture has many comparison instructions, including some that
extend one of the operands.  The signed comparison instructions use sign
extensions and the unsigned comparison instructions use zero extensions.
In cases where we had a free choice between signed or unsigned comparisons,
we were trying to decide at lowering time which would best fit the available
instructions, taking things like extension type into account.  The code
to do that was getting increasingly hairy and was also making some bad
decisions.  E.g. when comparing the result of two LLCs, it is better to use
CR rather than CLR, since CR can be fused with a branch while CLR can't.

This patch removes the lowering code and instead adds an operand to
integer comparisons to say whether signed comparison is required,
whether unsigned comparison is required, or whether either is OK.
We can then leave the choice of instruction up to the normal isel code.

llvm-svn: 190138

llvm-svn: 190137

llvm-svn: 190136

[tsan] make calloc crash instead of returning 0 on overflow (controlled by the allocator_may_return_null flag)

llvm-svn: 190135

No functional change

llvm-svn: 190134

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190133

[msan] make calloc crash instead of returning 0 on overflow (controlled by the allocator_may_return_null flag)

llvm-svn: 190132

No functional change

llvm-svn: 190131

llvm-svn: 190130

so allow that case and add appropriate tests.

Patch by Ruiling Song!

llvm-svn: 190129

[asan] make calloc crash instead of returning 0 on overflow (controlled by the allocator_may_return_null flag)

llvm-svn: 190128

[sanitizer] make the allocator crash instead of returning 0 on huge size (controlled by the allocator_may_return_null flag)

llvm-svn: 190127

Before:
  FirstToken->WhitespaceRange.getBegin()
      .getLocWithOffset(First->LastNewlineOffset);

After:
  FirstToken->WhitespaceRange.getBegin().getLocWithOffset(
      First->LastNewlineOffset);

Re-add logic to prevent breaking after an empty set of parentheses.
Basically it seems that calling a function without parameters is more
like navigating along the same object than it is a separate step of a
builder-type call.

We might need to extends this in future to allow "short" parameters that
e.g. are an index accessing a specific element.

llvm-svn: 190126

Summary:
If a noreturn destructor is executed while returning a value from a function,
the resulting CFG has had two edges to the exit block. This crashed the analyzer,
because it expects that blocks with no terminators have only one outgoing edge.
I added code to avoid creating the second edge in this case.

PS: The crashes did not manifest themselves always, as usually the
NoReturnFunctionChecker would stop program evaluation before the analyzer hit
the assertion, but in the case of lifetime extended temporaries, the checker
failed to do that (which is a separate bug in itself).

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1513

llvm-svn: 190125

Before:
  if (aaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaa(
          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) == 5) ...

After:
  if (aaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaa(
          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
      == 5) ...

Also precompute startsBinaryExpression() to improve performance.

llvm-svn: 190124

This fixes two issues:
1) The indent of a line comment was not adapted to the subsequent
   statement as it would be outside of a nested block.
2) A missing DryRun flag caused actualy breaks to be inserted in
   overly long comments while trying to come up with the best line
   breaking decisions.

llvm-svn: 190123

PR17046, PR17092: Debug Info assert-on-valid due to member loss when context creation recreates the item the context is created for

By removing the possibility of strange partial definitions with no
members that older GCC's produced for the otherwise unreferenced outer
types of referenced inner types, we can simplify debug info generation
and correct this bug. Newer (4.8.1 and ToT) GCC's don't produce this
quirky debug info, and instead produce the full definition for the outer
type (except in the case where that type is dynamic and its vtable is
not emitted in this TU).

During the creation of the context for a type, we may revisit that type
(due to the need to visit template parameters, among other things) and
used to end up visiting it first there. Then when we would reach the
original code attempting to define that type, we would lose debug info
by overwriting its members.

By avoiding the possibility of latent "defined with no members" types,
we can be sure than whenever we already have a type in a cache (either a
definition or declaration), we can just return that. In the case of a
full definition, our work is done. In the case of a partial definition,
we must already be in the process of completing it. And in the case of a
declaration, the completed/vtable/etc callbacks can handle converting it
to a definition.

llvm-svn: 190122

llvm-svn: 190121

llvm-svn: 190120

llvm-svn: 190119

This expands very slightly what -Wtautological-compare considers to be
tautological to include implicit accesses to C++ fields and ObjC ivars.
I don't want to turn this into a full expression-identity check, but
these additions seem pretty well-contained, and maintain the theme
of checking for "x == x".

<rdar://problem/14431127>

llvm-svn: 190118

llvm-svn: 190117

Consumed Analysis: The 'consumable' attribute now takes a identifier specifying the default assumed state for objects of this class

This information is used for return states and pass-by-value parameter
states.

Patch by Chris Wailes.

Review by DeLesley Hutchins and Aaron Ballman.

llvm-svn: 190116

initializer list containing a single element of type T, be sure to mark the
sequence as a list conversion sequence so that it is known to be worse than an
implicit conversion sequence that initializes a std::initializer_list object.

llvm-svn: 190115

Without this patch, TreeTransform::TransformExpr uses a ridiculous amount of
stack space (around 5000 bytes).  Preventing inlining brings the stack usage
down to something sane.

On a testcase I have, on my computer, this allows changing -ftemplate-depth
from 210 to around 750 before we crash.  I'm not sure I should commit the
testcase, though: I don't want to cause test failures on platforms with less
stack space available.

<rdar://problem/14098189>.

llvm-svn: 190114

llvm-svn: 190113

llvm-svn: 190112

constructor.

llvm-svn: 190111

llvm-svn: 190110

Consider something like the following:

struct X {
  virtual void foo(float x);
};
struct Y : X {
  void foo(double x) override;
};

The error is almost certainly that Y::foo() has the wrong signature,
rather than incorrect usage of the override keyword.  This patch
adds an appropriate diagnostic for that case.

Fixes <rdar://problem/14785106>.

llvm-svn: 190109

Just a minor tweak to make it easier to track down the cause of fatal errors
with modules.

llvm-svn: 190108