llvm-svn: 187896

llvm-svn: 187895

// rdar://14258334

llvm-svn: 187893

Before:
  #pragma omp reduction( | : var)
After:
  #pragma omp reduction(| : var)

llvm-svn: 187892

This field is just IsDefaulted && !IsDeleted; in all places it's used,
a simple check for isDefaulted() is superior anyway, and we were forgetting
to set it in a few cases.

Also eliminate CXXDestructorDecl::IsImplicitlyDefined, for the same reasons.

No intended functionality change.

llvm-svn: 187891

llvm-svn: 187890

llvm-svn: 187889

Patch by David Wiberg.

llvm-svn: 187888

llvm-svn: 187887

For now, builders in bb.pgr.jp are using it.

llvm-svn: 187886

If there's a race between a memory access and a free() call in the client program,
it can be reported as a use-after-free (if the access occurs after the free()) or an ordinary race
(if free() occurs after the access).
We've decided to use a single "race:" prefix for both cases instead of introducing a "use-after-free:" one,
because in many cases this allows us to keep a single suppression for both the use-after-free and free-after-use.

This may be misleading if the use-after-free occurs in a non-racy way (e.g. in a single-threaded program).
But normally such bugs shall not be suppressed.

llvm-svn: 187885

with lowering logic and a test.

llvm-svn: 187884

This follows the same lines as the integer code.  In the end it seemed
easier to have a second 4-bit mask in TSFlags to specify the compare-like
CC values.  That eats one more TSFlags bit than adding a CCHasUnordered
would have done, but it feels more concise.

llvm-svn: 187883

These instructions can also be used as comparisons with zero.

llvm-svn: 187882

llvm-svn: 187881

JumpThreading: Turn a select instruction into branching if it allows to thread one half of the select.

This is a common pattern coming out of simplifycfg generating gross code.

a:                                       ; preds = %entry
  %sel = select i1 %cmp1, double %add, double 0.000000e+00
  br label %b

b:
  %cond5 = phi double [ %sel, %a ], [ %sub, %entry ]
  %cmp6 = fcmp oeq double %cond5, 0.000000e+00
  br i1 %cmp6, label %if.then, label %if.end

becomes

a:
  br i1 %cmp1, label %b, label %if.then

b:
  %cond5 = phi double [ %sub, %entry ], [ %add, %a ]
  %cmp6 = fcmp oeq double %cond5, 0.000000e+00
  br i1 %cmp6, label %if.then, label %if.end

Skipping block b completely if possible.

llvm-svn: 187880

r187874 seems to have been missed by the build bot infrastructure, and
the subsequent commits to compiler-rt don't seem to be queuing up new
build requsets. Hopefully this will.

As it happens, having the space here is the more common formatting. =]

llvm-svn: 187879

llvm-svn: 187878

llvm-svn: 187877

Re-applying with a more reliable test case.

llvm-svn: 187876

llvm-svn: 187875

using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.

This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.

The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).

If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.

llvm-svn: 187874

llvm-svn: 187873

llvm-svn: 187872

llvm-svn: 187871

llvm-svn: 187870

This value may be used uninitialized in SIInsertWaits::insertWait.
Found with MemorySanitizer.

llvm-svn: 187869

lld has a hashtable with StringRef keys; it needs to iterate over the keys in
*insertion* order.  This is currently implemented as std::vector<StringRef> +
DenseMap<StringRef, T>.  This will probably need a proper
DenseMapInfo<StringRef> if we don't want to lose memory/performance by
migrating to a different data structure.

llvm-svn: 187868

llvm-svn: 187867

for StringRef with a StringMap

The bug is that the empty key compares equal to the tombstone key.

Also added an assertion to DenseMap to catch similar bugs in future.

llvm-svn: 187866

This removes a formatting choice that was added at one point, but is
not generally liked by users. Specifically, in builder-type calls, do
(easily) break if the object before the ./-> is either a field or a
parameter-less function call. I.e., don't break after "aa.aa.aa" or
"aa.aa.aa()". In general, these sequences in builder-type calls are
seen as a single entity and thus breaking them up is a bad idea.

llvm-svn: 187865

As of this revision, all functions of LTOCodeGenerator are consistent in
ret-true-on-succ.

Tested on multiple OSes.

llvm-svn: 187864

llvm-svn: 187863

llvm-svn: 187862

llvm-svn: 187861

llvm-svn: 187860

llvm-svn: 187859

llvm-svn: 187858

llvm-svn: 187857

llvm-svn: 187856