Currently the added test produces false race reports with glibc 2.19,
because DLTS memory is reused by pthread under the hood.

Use the DTLS machinery to intercept new DTLS ranges.
__tls_get_addr known to cause issues for tsan in the past,
so write the interceptor more carefully.

Reviewed in http://reviews.llvm.org/D20927

llvm-svn: 271568

llvm-svn: 271567

llvm-svn: 271566

I was appending to the wrong variable (over-zealous copy-paste from llvm on my part).

llvm-svn: 271565

Summary:
Adds StructInfo to CacheFragInfo to match the LLVM's EfficiencySanitizer
structs.

Uses StructHashMap to keep track of the struct info used by the app.

Adds registerStructInfo/unregisterStructInfo to add/remove struct infos
to/from StructHashMap.

updates test struct-simple.cpp with more C structs.

Reviewers: aizatsky, filcab

Subscribers: filcab, zhaoqin, llvm-commits, eugenis, vitalybuka, kcc, bruening, kubabrecka

Differential Revision: http://reviews.llvm.org/D20590

llvm-svn: 271564

r271558 introduced.

llvm-svn: 271563

llvm-svn: 271562

If the processor name failed to parse for amdgcn,
the resulting output would have R600 ISA in it.

If the processor name was missing or invalid for R600,
the wavefront size would not be set and there would be
crashes from missing itinerary data.

Fixes crashes in future commit caused by dividing by the unset/0
wavefront size.

llvm-svn: 271561

Summary:
This CL adds a weak check for a Vtable prefix: for a well-formed
Vtable, we require the prefix to be within [-1<<20; 1<<20].

Practically, this solves most of the known cases when UBSan segfaults
without providing any useful diagnostics.

Reviewers: pcc

Subscribers: kubabrecka

Differential Revision: http://reviews.llvm.org/D19750

llvm-svn: 271560

We've been pretending that segments are i8imm since the initial
support (r68645), predating the addition of the SEGMENT_REG class
(r81895).  That happens to works, but is wrong, and inconsistent
with how we print (e.g., X86ATTInstPrinter::printMemReference)
and parse them (e.g., X86Operand::addMemOperands).

This change shouldn't affect any tool users, but is visible to
library users or out-of-tree tablegen backends: this causes
MCOperandInfo for the segment op to have an RC instead of "unknown",
and TII::getRegClass to actually return something.  As the registers
are reserved and no vregs of the class ever created, that shouldn't
change anything.

No test change; no suspicious getRegClass() in X86 and CodeGen.

llvm-svn: 271559

D19271.

Previous attempt was broken by NetBSD, so in this version I've made the
fallback path generic rather than Windows specific and sent both Windows
and NetBSD to it.

I've also re-formatted the code some, and used an exact clone of the
code in PassSupport.h for doing manual call-once using our atomics
rather than rolling a new one.

If this sticks, we can replace the fallback path for Windows with
a Windows-specific implementation that is more reliable.

Original commit message:
This patch adds an llvm_call_once which is a wrapper around
std::call_once on platforms where it is available and devoid
of bugs. The patch also migrates the ManagedStatic mutex to
be allocated using llvm_call_once.

These changes are philosophically equivalent to the changes
added in r219638, which were reverted due to a hang on Win32
which was the result of a bug in the Windows implementation
of std::call_once.

Differential Revision: http://reviews.llvm.org/D5922

llvm-svn: 271558

Unlike other sections that can grow to any size, the COFF section header
stream has maximum length because each record is fixed size and the COFF
file format limits the maximum number of sections. So I decided to not
create a specific stream class for it. Instead, I added a member function
to DbiStream class which returns a vector of COFF headers.

Differential Revision: http://reviews.llvm.org/D20717

llvm-svn: 271557

This is part of an effort to shave allocations from APInt heavy paths.  I'll
be moving many of the other operators to r-value references soon and this is
a step towards doing that without too much duplication.

Saves 15k allocations when doing 'opt -O2 verify-uselistorder.bc'.

llvm-svn: 271556

Testing for specific CPUs has a number of problems, better use subtarget
features:
- When some tweak is added for a specific CPU it is often desirable for
  the next version of that CPU as well, yet we often forget to add it.
- It is hard to keep track of checks scattered around the target code;
  Declaring all target specifics together with the CPU in the tablegen
  file is a clear representation.
- Subtarget features can be tweaked from the command line.

To discourage people from using CPU checks in the future I removed the
isCortexXX(), isCyclone(), ... functions. I added an getProcFamily()
function for exceptional circumstances but made it clear in the comment
that usage is discouraged.

Reformat feature list in AArch64.td to have 1 feature per line in
alphabetical order to simplify merging and sorting for out of tree
tweaks.

No functional change intended.

Differential Revision: http://reviews.llvm.org/D20762

llvm-svn: 271555

This is effectively NFC because we already do this transform after r175380:
http://reviews.llvm.org/rL175380

and also via foldBoolSextMaskToSelect().

This change should just make it a bit more efficient to match the pattern. 
The original guard was added in r95058:
http://reviews.llvm.org/rL95058

A sampling of codegen for current in-tree targets shows no problems. This
makes sense given that we're already producing the vector selects via the
other transforms.

llvm-svn: 271554

Summary:
Also convert test/CodeGen/PowerPC/vsx-ldst-builtin-le.ll to use
FileCheck instead of two grep and count runs.

This change is needed to avoid spurious diffs in these tests when
EarlyCSE is improved to use MemorySSA and can do more load elimination.

Reviewers: hfinkel

Subscribers: mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D20238

llvm-svn: 271553

Useful for when we add MOVNTDQA support

llvm-svn: 271552

Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.

This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found.  Finally, it adds a test case.

<rdar://problem/25094302>

llvm-svn: 271551

The DIType* for void is the null pointer. A null DIType can never be a
qualified type, so we can just exit the loop at this point and go to
getTypeIndex(BaseTy).

Fixes PR27984

llvm-svn: 271550

This matches the COFF spec

llvm-svn: 271549

Summary:
In PR29973 Sanjay Patel reported an assertion failure when a certain
loop was optimized, for a target without SSE2 support.  It turned out
this was because of the AVG pattern detection introduced in rL253952.

Prevent the assertion failure by bailing out early in
`detectAVGPattern()`, if the target does not support SSE2.

Also add a minimized test case.

Reviewers: congh, eli.friedman, spatel

Subscribers: emaste, llvm-commits

Differential Revision: http://reviews.llvm.org/D20905

llvm-svn: 271548

Summary:
Fills the cfrag struct variable with an array of struct information
variables.

Reviewers: aizatsky, bruening

Subscribers: bruening, kcc, vitalybuka, eugenis, llvm-commits, zhaoqin

Differential Revision: http://reviews.llvm.org/D20661

llvm-svn: 271547

Also fix slice wrappers drop_front and drop_back.
The unittests are pretty awkward, but do the job; alternatives
welcome!

..and yes, I do have ArrayRefs with more than 4 billion elements.

llvm-svn: 271546

LLDB needs to be able to handle DW_AT_GNU_dwo_name that are relative to the DW_AT_comp_dir when using -gmodules with DWARF in .o files on darwin.

<rdar://problem/26590227> 

llvm-svn: 271545

llvm-svn: 271544

Fixed a problem where -gmodules debug info would be loaded by the DWO file support accidentally and cause 1000s of files to be mapped into LLDB's address space for each .o file that reference a module.

<rdar://problem/26580266> -gmodules causes LLDB.framework to map hundreds of copies of the same .pcm file

llvm-svn: 271543

Do not issue lexing errors found during the parsing of macro body
definitions and parseIdentifier function in AsmParser. This changes the
Parser to not issue a lexing error when we reach an error, but rather
when it is consumed allowing us time to examine and recover from an
error.

As a result, of this, we stop issuing a both lexing error and a parsing
error in floating-literals test. Minor tweak to parseDirectiveRealValue
to favor more meaningful lexing error over less helpful parse error.

Reviewers: rnk, majnemer

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D20535

llvm-svn: 271542

We still need to do something about member functions and calling
conventions.

Differential Revision: http://reviews.llvm.org/D20900

llvm-svn: 271541

except for CompareAndSwap. That is the only one still being used
anywhere now that statistics have been moved onto std::atomic.

Also, add a warning to the header that we shouldn't introduce more uses
of these old style atomics and instead should be using C++11's
std::atomic facilities.

Really hoping that we can hammer out the last couple of users here and
replace them with something more localized and/or principled, but
figured this was a pretty good start. =]

Note that this patch will need to be reverted if r271504 needs to be
reverted as that removes the last user of these. However, the biggest
risk for that patch was MSVC 2013 and at least one bot has already
passed where it would have failed there. I've tested MSVC 2015 using
their web interfaces and other platforms seem fine, so I'm optimistic.

Differential Revision: http://reviews.llvm.org/D20901

llvm-svn: 271540

This directory is used to find if there is a PDB associated with an
executable. I plan to use this functionality to teach llvm-symbolizer
whether it should use DIA or DWARF to symbolize a given DLL.

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D20885

llvm-svn: 271539

  Operands of binary operations that might overflow will be temporarily
  promoted to i64 again, though that is not a sound solution for the problem.

llvm-svn: 271538

llvm-svn: 271537

Summary:
After rL271151 (SCEV change) SCEV no longer unconditionally transfers
nuw/nsw from the increment operation to the post-inc value; this
transfer only happens if there is undefined behavior in the program if
the increment overflowed (as opposed to just generating poison).

The loops in `wraping_signed_expr_1.ll` are in non-canonical
form (they're not rotated), and that defeats LLVM's poison-is-UB
analysis.  IMO the easiest fix here is to run `wraping_signed_expr_1.ll`
through `-loop-rotate` to canonicalize the loops, which is what this
patch does.

Reviewers: jdoerfert, Meinersbur, grosser

Subscribers: grosser, mcrosier, pollydev

Differential Revision: http://reviews.llvm.org/D20778

llvm-svn: 271536

llvm-svn: 271535

llvm-svn: 271534

Summary:
When this flag is specified, the target llvm-lto is not built, but is still
used as a dependency of the test targets. cmake 2.8 silently ignored this
situation, but with cmake_minimum_required(3.4) it becomes an error. Fix this
by avoiding the inclusion the target as a dependency.

Reviewers: beanz

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20883

llvm-svn: 271533

Inline virtual functions has linkeonceodr linkage (emitted in comdat on 
supporting targets). If the vtable for the class is not emitted in the
defining module, function won't be address taken thus its address is not
recorded. At the mercy of the linker, if the per-func prf_data from this
module (in comdat) is picked at link time, we will lose mapping from
function address to its hash val. This leads to missing icall promotion.
The second test case (currently disabled) in compiler_rt (r271528): 
instrprof-icall-prom.test demostrates the bug. The first profile-use
subtest is fine due to linker order difference.

With this change, no missing icall targets is found in instrumented clang's
raw profile.

llvm-svn: 271532

llvm-svn: 271531

Summary:
When this flag is specified, the target llvm-lto is not built, but is still
used as a dependency of the test targets. cmake 2.8 silently ignored this
situation, but with cmake_minimum_required(3.4) it becomes an error. Fix this
by avoiding the inclusion of the target as a dependency.

Reviewers: beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D20882

llvm-svn: 271530

llvm-svn: 271529