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

llvm-svn: 193010

llvm-svn: 193009

Update to reflect current GC APIs and usage. The example code is taken from the Erlang GC implementation.

llvm-svn: 193008

llvm-svn: 193007

llvm-svn: 193006

test also adds FIXMEs for a number of places where imports and includes of
submodules don't work very well.

llvm-svn: 193005

llvm-svn: 193004

attributes when such methods are actually envoked in message
expression. // rdar://15242010

llvm-svn: 193003

With this commit, all DIEs created in CompileUnit will be added to parents
inside the same function. Also make getOrCreateTemplateType|Value functions
private.

No functionality change.

llvm-svn: 193002

llvm-svn: 193001

This is another (final?) stab at making us able to parse our own asm output
on Windows.

Symbols on Windows often contain @'s and ?'s in their names. Our asm parser
didn't like this. ?'s were not allowed, and @'s were intepreted as trying to
reference PLT/GOT/etc.

We can't just add quotes around the bad names, since e.g. for MinGW, we use gas
to assemble, and it doesn't like quotes in some places (notably in .def
directives).

This commit makes us allow ?'s in symbol names, and @'s in symbol names for MS
assembly.

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

llvm-svn: 193000

llvm-svn: 192999