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

llvm-svn: 192997

Thanks to Milan Lenčo for noticing it.

llvm-svn: 192996

in the "uknown" state.  Patch by chris.wailes@gmail.com.  Reviewed by delesley.

llvm-svn: 192995

llvm-svn: 192994

Removing Host/Atomic.h
This header file was not being copied as part of our public API headers and this in turn was causing any plugin to link against LLDB.framework, since SharingPtr.h depends on it

Out of several possible options to fix this issue, the cleanest one is to revert LLDB to use std::atomic<>, as we are a C++11 project and should take advantage of it

The original rationale for going from std::atomic to Host/Atomic.h was that MSVC++ fails to link in CLR mode when std::atomic is used
This is a very Visual Studio/.net specific issue, which hopefully will be fixed
Until them, to allow Windows development to proceed, we are going with a targeted solution where we #ifdef include the Windows specific calls, and let everyone else use the
proper atomic support, as should be

If there is an unavoidable need for a LLDB-specific atomic header, the right way to go at it would be to make an API/lldb-atomic.h header and #ifdef the Windows dependency there

The FormatManager should not need to conditionalize use of std::atomic<>, as other parts of the LLDB internals are successfully using atomic (Address and IRExecutionUnit), so this
Win-specific hack is limited to SharingPtr

llvm-svn: 192993

specified.

In particular it makes sure that  relative paths for non-virtual files aren't
made absolute.
Added unittest.

llvm-svn: 192992

default constructor.  Patch by chris.wailes@gmail.com, reviewed by delesley.

llvm-svn: 192991

llvm-svn: 192990

<rdar://problem/15252474>

llvm-svn: 192989