Before (note the missing space before "..." which can lead to compile
errors):
  switch (x) {
    case 'A'... 'Z':
    case 1... 5:
        break;
  }

After:
  switch (x) {
    case 'A' ... 'Z':
    case 1 ... 5:
        break;
  }

llvm-svn: 193050

Before:
  NSDictionary *d = @{ @"nam" : NSUserNam(), @"dte" : [NSDate date],
                       @"processInfo" : [NSProcessInfo processInfo]
  };

After:
  NSDictionary *d = @{
    @"nam" : NSUserNam(),
    @"dte" : [NSDate date],
    @"processInfo" : [NSProcessInfo processInfo]
  };

llvm-svn: 193049

Driver: libubsan_cxx depends on libubsan. Preserve the topological ordering, some linkers depend on it.

llvm-svn: 193048

llvm-svn: 193047

llvm-svn: 193046

One optimization simplify-cfg performs is the converting of switches to
lookup tables if the switch has > 4 cases. This is done by:

1. Finding the max/min case value and calculating the switch case range.
2. Create a lookup table basic block.
3. Perform a check in the switch's BB to see if the input value is in
the switch's case range. If the input value satisfies said predicate
branch to the lookup table BB, otherwise branch to the switch's default
destination BB using the default value as the result.

The conditional check consists of subtracting the min case value of the
table from any input iN value and then ensuring that said value is
unsigned less than the size of the lookup table represented as an iN
value.

If the lookup table is a covered lookup table, the size of the table will be N
which is 0 as an iN value. Thus the comparison will be an `icmp ult` of an iN
value against 0 which is always false yielding the incorrect result.

This patch fixes this problem by recognizing if we have a covered lookup table
and if we do, unconditionally jumps to the lookup table BB since the covering
property of the lookup table implies no input values could not be handled by
said BB.

rdar://15268442

llvm-svn: 193045

This fixes PR17591.

N.B. This actually goes beyond what the standard mandates by requiring
the restriction to hold for declarations instead of definitions.  This
is believed to be a defect in the standard and an LWG issue has been
submitted.

llvm-svn: 193044

llvm-svn: 193043

This ensures that the prefix data is treated as part of the function for
the purpose of debug info.  This provides a better debugging experience,
among other things by allowing a debug info client to correctly look up
a function in debug info given a function pointer.

llvm-svn: 193042

r182712 attempted to do this, but it failed to handle data emitted via
EmitBytes.

llvm-svn: 193041

llvm-svn: 193040

* NamedDecl and CXXMethodDecl were missing getMostRecentDecl.
* The const version can just forward to the non const.
* getMostRecentDecl can use cast instead of cast_or_null.

This then removes some casts from the callers.

llvm-svn: 193039

llvm-svn: 193038

Thanks to David Blaikie for noticing it.

llvm-svn: 193037

Thanks to Sean Silva for the suggestion.

llvm-svn: 193036

If the predecessor's being spliced into a landing pad, then we need the PHIs to
come first and the rest of the predecessor's code to come *after* the landing
pad instruction.

llvm-svn: 193035

llvm-svn: 193034

llvm-svn: 193033

llvm-svn: 193032

llvm-svn: 193031

llvm-svn: 193030

This patch fixes a bug in r190608. The results of a comparison function
passed to std::sort must be transitive, which is, if a < b and b < c, and if
a != b, a < c must be also true. CompareAtoms::compare did not actually
guarantee the transitivity. As a result the sort results were sometimes just
wrong.

Consider there are three atoms, X, Y, and Z, whose file ordinals are 1, 2, 3,
respectively. Z has a property "layout-after X". In this case, all the
following conditionals become true:

  X < Y because X's ordinal is less than Y's
  Y < Z because Y's ordinal is less than Z's
  Z < X because of the layout-after relationship

This is not of course transitive. The reason why this happened is because
we used follow-on relationships for comparison if two atoms falls in the same
follow-on chain, but we used each atom's properties if they did not. This patch
fixes the issue by using follow-on root atoms for comparison to get consistent
results.

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

llvm-svn: 193029

llvm-svn: 193028

Redeclarable already had a isFirstDecl, but it was missing from DeclBase.

llvm-svn: 193027

llvm-svn: 193026

llvm-svn: 193025

llvm-svn: 193024

llvm-svn: 193023

pick up the common bits ubsan actually needs. Also remove whole-archive when we
aren't trying to re-export the symbols.

llvm-svn: 193022

llvm-svn: 193021

Now that CorrectTypo knows how to correctly search classes for typo
correction candidates, there is no good reason to only replace an
existing CXXScopeSpecifier if it refers to a namespace. While the actual
enablement was a matter of changing a single comparison, the fallout
from enabling the functionality required a lot more code changes
(including my two previous commits).

llvm-svn: 193020

NestedNameSpecifier that replaces an existing specifier.

llvm-svn: 193019

essentially the same.

llvm-svn: 193018

We should dead-strip atoms only if they are created for COMDAT symbols. If we
remove non-COMDAT atoms from a binary, it will no longer be guaranteed that
the binary will work correctly.

In COFF, you can manipulate the order of section contents in the resulting
binary by section name. For example, if you have four sections
.data$unique_prefix_{a,b,c,d}, it's guaranteed that the contents of A, B, C,
and D will be consecutive in the resulting .data section in that order.
Thus, you can access B's and C's contents by incrementing a pointer pointing
to A until it reached to D. That's why we cannot dead-strip B or C even if
no one is directly referencing to them.

Some object files in the standard library actually use that technique.

llvm-svn: 193017

and unions the same way that C would.

<rdar://problem/11987906>

llvm-svn: 193016

SCEV currently fails to compute loop counts for nonunit stride
loops. This comes up frequently. It prevents loop optimization and
forces vectorization to insert extra loop checks.

For example:
void foo(int n, int *x) {
 for (int i = 0; i < n; i += 3) {
   x[i] = i;
   x[i+1] = i+1;
   x[i+2] = i+2;
 }
}

We need to properly handle the case in which limit > INT_MAX-stride. In
the above case: n > INT_MAX-3. In this case the loop counter will step
beyond the limit and overflow at the same time. However, knowing that
signed integer overlow in undefined, we can assume the loop test
behavior is arbitrary after overflow. This obeys both C undefined
behavior rules, and the more strict LLVM poison value rules.

I'm finally fixing this in response to Hal Finkel's persistence.
The most probable reason that we never optimized this before is that
we were being careful to handle case where the developer expected a
side-effect free infinite loop relying on overflow:

for (int i = 0; i < n; i += s) {
  ++j;
}
return j;

If INT_MAX+1 is a multiple of s and n > INT_MAX-s, then we might
expect an infinite loop. However there are plenty of ways to achieve
this effect without relying on undefined behavior of signed overflow.

llvm-svn: 193015

llvm-svn: 193014

llvm-svn: 193013

llvm-svn: 193012

llvm-svn: 193011