Fix trivial signed/unsigned comparison warnings

llvm-svn: 224932

irgen: remove unused compiler.runtimetypespkg field.

llvm-svn: 224931

[cmake/multilib] Teach LLDB to respect the multlib LLVM_LIBDIR_SUFFIX
variable (now provided both by the normal parent LLVM CMake files and by
the LLVMConfig.cmake file used by the standalone build).

This allows LLDB to build into and install into correctly suffixed
libdirs. This is especially significant for LLDB because the python
extension building done by CMake directly uses multilib suffixes when
the host OS does, and the host OS will not always look back and forth
between them. As a consequence, before LLVM, Clang, and LLDB (and every
other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't
build or install LLDB on a multilib system with its python extensions
enabled. With this patch (on top of all the others I have submitted
throughout the project), I'm finally able to build and install LLDB on
my system with Python support enabled. I'm also able to actually run the
LLDB test suite, etc. Now, a *huge* number of the tests still fail on my
Linux system, but hey, actually running them and them testing the
debugger is a huge step forward. =D

llvm-svn: 224930

[cmake] Teach the standalone CMake build to find the Python interpreter
the same way the LLVM CMake build does, notably using the proper CMake
module and specifically requesting an older Python version. LLDB relies
pretty heavily on not using Python 3 at this point, and without this
patch it ends up trying to use Python 3 which ends quite badly. =] With
this, I'm able to build LLDB in its standalone mode successfully on
Linux when I have both Python 2.7 and Python 3.3 installed.

llvm-svn: 224929

[cmake/multilib] Support multilib libdir suffixes by applying the
LLVM_LIBDIR_SUFFIX variable to one place in the cmake file.

This is all that I had to do to get everything from compiler-rt working
for me, but there may be more work required if folks are relying on more
parts of compiler-rt. Notably, I'm mostly using it for the sanitizers.

llvm-svn: 224928

[cmake/multilib] Teach libc++abi's CMake build to support multilib
libdir suffixes like 'lib64' or 'lib32'.

This support is currently very rhudimentary. We define a variable
LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++abi within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.

Unfortunately, libc++abi's lit setup made this somewhat problematic to
change. It was setting variables up in a way that caused the resulting
build to not work with lit at all. To fix that, I've moved some
variables around in the CMake build to more closely match where and how
they are defined in the libc++ CMake build. This includes specifically
defining a library root variable in the CMake build where the libdir
suffix can be applied, and then using that rather than re-computing it
from the object directory in the lit config.

This is essentially new functionality for libc++abi so I don't expect it
to have any impact for folks until they start setting these variables.
However, I know libc++abi is built in a diverse set of environments so
just let me know if this causes you any problems.

llvm-svn: 224927

[cmake/multilib] Teach libc++'s CMake build to support multilib libdir
suffixes like 'lib64' or 'lib32'.

This support is currently very rhudimentary. We define a variable
LIBCXX_LIBDIR_SUFFIX. In a standalone build of libc++ this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++ within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.

This is essentially new functionality for libc++ so I don't expect it to
have any impact for folks until they start setting these variables.
However, I know libc++ is built in a diverse set of environments so just
let me know if this causes you any problems.

llvm-svn: 224926

[multilib] Teach LLD's CMake build to use LLVM_LIBDIR_SUFFIX which
allows it to support multilib suffixed hosts using lib64, etc. This
variable is now available both in the direct LLVM build and from the
LLVMConfig.cmake file used by standalone builds.

llvm-svn: 224925

[multilib] Teach Clang's code about multilib by threading
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.

Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.

This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.

I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.

Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.

llvm-svn: 224924

[cmake] Teach the Clang CMake build to use LLVM_LIBDIR_SUFFIX for its
'lib' directories in the build. This variable is available now both as
part of the normal LLVM build an as part of a standalone build as I've
added it to the LLVMConfig.cmake output.

With this change we should at least put libraries into the multilib
directory correctly. It is the first step in getting Clang to be
reasonably multilib aware.

llvm-svn: 224923

[multilib] Add support to the autoconf build to substitute
a CLANG_LIBDIR_SUFFIX variable. This is necessary before I can add
support for using that variable to CMake and the C++ code in Clang, and
the autoconf build system does all substitutions in the LLVM tree.

As mentioned before, I'm not planning to add actual multilib support to
the autoconf build, just enough stubs for it to keep playing nicely with
the CMake build once that one has support.

llvm-svn: 224922

[cmake] Teach the llvm-config program to respect LLVM_LIBDIR_SUFFIX.

For this to work, we have to encode it in the build variables and use it
from llvm-config.cpp. I've tried to do this reasonably cleanly, but the
code for llvm-config.cpp is pretty strange. However, with this,
llvm-config stops giving the wrong answer when using LLVM_LIBDIR_SUFFIX.

Note that the configure+make build just sets this to an empty string as
that build system has zero support for multilib of any form. I'm not
planning to add support there either, but this should leave a path for
anyone that wanted to.

llvm-svn: 224921

[cmake] Push LLVM_LIBDIR_SUFFIX through to the LLVMConfig.cmake file
that is used by other projects to build against LLVM. This will allow
subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as
part of the larger LLVM build an as part of a standalone build against
an installed set of LLVM libraries.

llvm-svn: 224920

[cmake] Start making LLVM_LIBDIR_SUFFIX effective by adding it to
*numerous* places where it was missing in the CMake build. The primary
change here is that the suffix is now actually used for all of the lib
directories in the LLVM project's CMake. The various subprojects still
need similar treatment.

This is the first of a series of commits to try to make LLVM's cmake
effective in a multilib Linux installation. I don't think many people
are seriously using this variable so I'm hoping the fallout will be
minimal. A somewhat unfortunate consequence of the nature of these
commits is that until I land all of them, they will in part make the
brokenness of our multilib support more apparant. At the end, things
should actually work.

llvm-svn: 224919

Sema: Permit array l-values in asm output operands

GCC permits array l-values in asm output operands even though they
aren't modifiable l-values.  We used to permit it but this behavior
regressed in r224916.

llvm-svn: 224918

Fixed 2 minor typos in the documentation.

llvm-svn: 224917

Sema: Only permit permit modifiable l-values as asm output params

Functions are l-values in C++ but shouldn't be available as output
parameters in inline assembly.  Neither should overloaded function
l-values.

This fixes PR21949.

llvm-svn: 224916

Don't crash on malformed attributes in an incorrect location.

r168626 added nicer diagnostics for attributes in the wrong places, such as
after the `final` on a class.  To do this, it added code that did high-level
pattern matching for e.g. 'final' 'alignas' '(' and then skipped until the
closing ')'.  If it saw that, it then went down the regular class parsing
path and then called MaybeParseCXX11Attributes() to parse the attribute after
the 'final' using real attribute parsing code.  On invalid attributes, the
real attribute parsing code could eat more tokens than the pattern matching
code and for example skip past the '{' starting the class, which would then
lead to an assert.  To prevent this, check for a good state after calling
MaybeParseCXX11Attributes() (which morphed into CheckMisplacedCXX11Attribute()
in r175575) and bail out if things look bleak.

Found by SLi's afl bot.

llvm-svn: 224915

[x86] Fix an accidental commit of a change from Ii to iC on __builtin_ia32_cmpps512_mask.

llvm-svn: 224914

[x86] Put 'C' after 'i' on all the AVX-512 intrisics that take const ints. 'C' is a suffix modifier not a prefix modififier. Also put 'C' on the pointers in all of the gather instrinsics. I think they previously had one due to the misordering. I'm still thinking the 'iC' actually need to be a 'Ii' since they really require an ICE.

llvm-svn: 224913

Sema: Don't crash when solitary :: token appears before { in struct def

hasDeclaratorForAnonDecl, getDeclaratorForAnonDecl and
getTypedefNameForAnonDecl are expected to handle the case where
NamedDeclOrQualifier holds the wrong type or nothing at all.

llvm-svn: 224912

Sema: Forbid inconsistent constraint alternatives

Verify that asm constraints have the same number of alternatives

llvm-svn: 224911

[sanitizer-common] Fixing the ASan test build failure on OS X

The change in r224819 started using internal_unlink in a sanitizer_common unit test. For some reason, internal_unlink is not defined in sanitizer_mac.cc, fixing that.

llvm-svn: 224910

SemaCXX: Don't crash when annotation tokens show up before the tag name

Clang has a hack to accept definitions of structs with tag names which
have the same name as intrinsics.  However, this hack didn't guard
against annotation tokens showing up in the token stream.

llvm-svn: 224909

CodeGen: Optimize emssion of zeroinitialzied arrays

Create an ConstantAggregateZero upfront if we see that it is viable.
This saves us from having to manually push_back each and every
initializer and then looping back over them to determine if they are
'null'.

llvm-svn: 224908

llvm/test/CodeGen/X86/fast-isel-call-bool.ll: Add explicit -mtriple=x86_64-unknown to satisfy x64.

llvm-svn: 224907

Don't crash on surprising tokens in default parameter template lists.

Fixes this snippet from SLi's afl fuzzer output:

  class {
      i (x = <, enum

This parsed i as a function, x as a paramter, and the stuff after < as a
template list.  This then called TryConsumeDeclarationSpecifier() which
called TryAnnotateCXXScopeToken() without checking the preconditions of
this function.  Check them before calling, like all other callers of
TryAnnotateCXXScopeToken() do.

A more readable reproducer that causes the same crash is

  class {
      void i(int x = MyTemplateClass<int, union int>::foo());
  };

The reduced version used an eof token as surprising token, but kw_int works
just as well to repro and is easier to insert into a test file.

llvm-svn: 224906

Sema: Variable templates cannot be static bitfield members

We correctly forbid variables but not variable templates.  Diagnose this
case instead of crashing.

llvm-svn: 224905

irgen: do not emit an extra terminator for panic thunks

Found with GoSmith.

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

llvm-svn: 224904

Parse: Don't crash when 'typename' shows up in an attribute

isDeclarationSpecifier performs error recovers which jostles the token
stream.  Specifically, TryAnnotateTypeOrScopeToken will end up consuming
a typename token which will confuse the attribute parsing machinery as
we no-longer have something identifier-like.

llvm-svn: 224903

Sema: Permit an atomic type to be initialized by the same atomic type

We forgot a conversion step when initializing an atomic type with an
rvalue of the same type.

This fixes PR22043.

llvm-svn: 224902

[X86][ISel] Fix a regression I introduced in r224884

The else case ResultReg was not checked for validity.
To my surprise, this case was not hit in any of the
existing test cases. This includes a new test cases
that tests this path.

Also drop the `target triple` declaration from the
original test as suggested by H.J. Lu, because
apparently with it the test won't be run on Linux

llvm-svn: 224901

[X86] Add missing memory variants to AVX false dependency breaking

Adds missing memory instruction variants to AVX false dependency breaking handling. (SSE was handled in r224246)

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

llvm-svn: 224900

[CodeGenPrepare] Teach when it is profitable to speculate calls to @llvm.cttz/ctlz.

If the control flow is modelling an if-statement where the only instruction in
the 'then' basic block (excluding the terminator) is a call to cttz/ctlz,
CodeGenPrepare can try to speculate the cttz/ctlz call and simplify the control
flow graph.

Example:
\code
entry:
  %cmp = icmp eq i64 %val, 0
  br i1 %cmp, label %end.bb, label %then.bb

then.bb:
  %c = tail call i64 @llvm.cttz.i64(i64 %val, i1 true)
  br label %end.bb

end.bb:
  %cond = phi i64 [ %c, %then.bb ], [ 64, %entry]
\code

In this example, basic block %then.bb is taken if value %val is not zero.
Also, the phi node in %end.bb would propagate the size-of in bits of %val
only if %val is equal to zero.

With this patch, CodeGenPrepare will try to hoist the call to cttz from %then.bb
into basic block %entry only if cttz is cheap to speculate for the target.

Added two new hooks in TargetLowering.h to let targets customize the behavior
(i.e. decide whether it is cheap or not to speculate calls to cttz/ctlz). The
two new methods are 'isCheapToSpeculateCtlz' and 'isCheapToSpeculateCttz'.
By default, both methods return 'false'.
On X86, method 'isCheapToSpeculateCtlz' returns true only if the target has
LZCNT. Method 'isCheapToSpeculateCttz' only returns true if the target has BMI.

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

llvm-svn: 224899

Sema: Don't crash when an inject class name has a nested redefinition

We expected the type of a TagDecl to be a TagType, not an
InjectedClassNameType.  Introduced a helper method, Type::getAsTagDecl,
to abstract away the difference; redefine Type::getAsCXXRecordDecl to be
in terms of it.

llvm-svn: 224898

Scalarizer for masked load and store intrinsics.

Masked vector intrinsics are a part of common LLVM IR, but they are really supported on AVX2 and AVX-512 targets. I added a code that translates masked intrinsic for all other targets. The masked vector intrinsic is converted to a chain of scalar operations inside conditional basic blocks.

http://reviews.llvm.org/D6436

llvm-svn: 224897

Lex: Don't let annotation tokens get into macro expansion

We'd let annotation tokens from '#pragma pack' and the like get inside a
function-like macro.  This would lead to terror and mayhem; stop the
madness early.

This fixes PR22037.

llvm-svn: 224896

Fix markup from r224894.

llvm-svn: 224895

Add stub sections about Parse, Sema, CodeGen to the internals manual.

I'd be interested if the paragraph on Parse not knowing much about AST is
something folks agree with.  I think this used to be true after rjmccall removed
the Action interface in r112244 and I believe it's still true, but I'm not sure.
(For example, ParseOpenMP.cpp does include AST/StmtOpenMP.h.  Other than that,
Parse not using AST nodes much seems to be still true, though.)

llvm-svn: 224894

Remove unneeded include of DeclCXX.h from libParse.

llvm-svn: 224893

Objective-C: Serialize "more than one decl" state of ObjCMethodList.

This fixes PR21587, what r221933 fixed for regular programs is now also
fixed for decls coming from PCH files.

Use another bit from the count/bits uint16_t for storing the "more than one
decl" bit.  This reduces the number of bits for the count from 14 to 13.
The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits
should still be plenty.  Since this changes the meaning of a serialized bit
pattern, also increase clang::serialization::VERSION_MAJOR.

Storing the "more than one decl" state of only the first overload isn't quite
correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at
the state of the first overload so it's good enough for now.

llvm-svn: 224892

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Correctly this time. I did the wrong patterns the first time.

llvm-svn: 224891

PowerPC: CTR shouldn't fire if a TLS call is in the loop

Determining the address of a TLS variable results in a function call in
certain TLS models.  This means that a simple ICmpInst might actually
result in invalidating the CTR register.

In such cases, do not attempt to rely on the CTR register for loop
optimization purposes.

This fixes PR22034.

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

llvm-svn: 224890

Fixing another -Wunused-variable warning, this time in release builds without asserts. NFC.

llvm-svn: 224889

Removing a variable that is set but never used, to silence a -Wunused-but-set-variable warning; NFC.

llvm-svn: 224888

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Forgot to do this when I did SSE/SSE2/AVX/AVX2.

llvm-svn: 224887

[x86] Assert on invalid immediates in the instruction printer for cmp.ps/pd/ss/sd instead of truncating the immediate. The assembly parser and instruction selection shouldn't generate invalid immediates.

llvm-svn: 224886

[x86] Prevent llvm.x86.cmp.ps/pd/ss/sd from being selected with bad immediates. The frontend now checks this when the builtin is used. This will allow the instruction printer to not have to deal with invalid immediates on these instructions.

llvm-svn: 224885

[FastIsel][X86] Fix invalid register replacement for bool args

Summary:
Consider the following IR:

  %3 = load i8* undef
  %4 = trunc i8 %3 to i1
  %5 = call %jl_value_t.0* @foo(..., i1 %4, ...)
  ret %jl_value_t.0* %5

Bools (that are the result of direct truncs) are lowered as whatever
the argument to the trunc was and a "and 1", causing the part of the
MBB responsible for this argument to look something like this:

  %vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7

Later, when the load is lowered, it will insert

  %vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14

but remember to (at the end of isel) replace vreg7 by vreg15. Now for
the bug. In fast isel lowering, we mistakenly mark vreg8 as the result
of the load instead of the trunc. This adds a fixup to have
vreg8 replaced by whatever the result of the load is as well, so
we end up with

  %vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15

which is an SSA violation and causes problems later down the road.

This fixes PR21557.

Test Plan: Test test case from PR21557 is added to the test suite.

Reviewers: ributzka

Reviewed By: ributzka

Subscribers: llvm-commits

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

llvm-svn: 224884

[x86] Also add the missing type casts on the returns in the sha
intrinsic header file. Along with r224822, this should restore the build
bots to passing.

llvm-svn: 224883

[x86] Add missing typecast to __v4si to sha intrinsic header file.

llvm-svn: 224882

Objective-C: Tweak unavailability warning.

Don't warn when a selector has an unavailable and an available variant,
and the first also has an implementation.

llvm-svn: 224881

[x86] Add range checking to the constant argument of cmpps/pd/ss/sd builtinas.

llvm-svn: 224880

[x86] Add the (v)cmpps/pd/ss/sd builtins to match gcc. Use them in the sse intrinsic files.

This still lower to the same intrinsics as before.

This is preparation for bounds checking the immediate on the avx version of the builtin so we don't pass illegal immediates into the backend. Since SSE uses a smaller size immediate its not possible to bounds check when using a shared builtin. Rather than creating a clang specific builtin for the different immediate, I decided (after consulting with Chandler) that it was better to match gcc.

llvm-svn: 224879

Add more feature flags to the x86 instrinsic test.

llvm-svn: 224878

Fix formatting. NFC.

llvm-svn: 224877

Address review feedback on r221933.

Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in
the low bit of the ObjCMethodDecl pointer, using a PointerIntPair.

Most of this patch is replacing ".Method" with ".getMethod()".

No intended behavior change.

llvm-svn: 224876

Make the test from r224873 actually pass.

The behavior looks incorrect to me, but the test is supposed to document
current behavior for now.

llvm-svn: 224875

Mark __builtin_ia32_cmppd256 and __builtin_ia32_cmpps256 as taking an ICE for the constant parameter.

llvm-svn: 224874

Add more test coverage for the Objective-C deprected selector warning.

I broke this case in a local patch I'm writing, and there was no test to stop
me.  Now there is.

llvm-svn: 224873

Convert test to llvm-readobj. NFC.

llvm-svn: 224872

[Hexagon] Adding auto-incrementing loads with and without byte reversal.

llvm-svn: 224871

[Hexagon] Adding locked loads.

llvm-svn: 224870

[Hexagon] Adding deallocframe and circular addressing loads.

llvm-svn: 224869

[Hexagon] Adding remaining post-increment instruction variants.  Removing unused classes.

llvm-svn: 224868

[Hexagon] Adding post-increment unsigned byte loads.

llvm-svn: 224867

[Hexagon] Adding post-increment signed byte loads with tests.

llvm-svn: 224866

Adjust the rest of the tests due to r224849.

llvm-svn: 224865

Use llvm-readobj. NFC.

llvm-svn: 224864

Escape ? to silence GCC warning about trigraphs.

llvm-svn: 224863

[X86] Add the debug registers DR8-DR15 so we can assemble and disassemble references to them.

llvm-svn: 224862

[X86] Don't fail disassembly if REX.R/REX.B is used on an MMX register. Similar fix to not fail to disassembler CR9-CR15 references.

llvm-svn: 224861

Band-aid fix for PR22032: don't emit DWARF debug info if AddressSanitizer is enabled on Windows

llvm-svn: 224860

No need to run llvm-as. NFC.

llvm-svn: 224859

[sanitizer] Treat \r, \n, \t as flag separators.

llvm-svn: 224858

[asan] Fix possibly uninitialized coverage flag.

llvm-svn: 224857

[ASan/Win] Add basic support for MemoryRangeIsAvailable and DumpProcessMap to make it easier to debug startup shadow mapping failures

llvm-svn: 224856

[asan] Bump coverage size limit on 32-bit platforms.

This increases the limit from 4M locations to 16M, reserving
64Mb virtual memory. Chrome has >5M unique coverage locations with coverage=3.

llvm-svn: 224855

[asan] Extend coverage test.

llvm-svn: 224854

[asan] Allow enabling coverage at activation.

This is a re-commit of r224838 + r224839, previously reverted in r224850.
Test failures were likely (still can not reproduce) caused by two lit tests
using the same name for an intermediate build target.

llvm-svn: 224853

[ASan/Win] Suppress error messaging when Abort() is called
This will prevent ASan bots from hanging / timing out

llvm-svn: 224852

Update tests due to r224849

Inferring nuw caused some clang tests to change their output.

llvm-svn: 224851

Revert r224838, r224839.

Flaky failures on the build bots.

llvm-svn: 224850

InstCombine: Infer nuw for multiplies

A multiply cannot unsigned wrap if there are bitwidth, or more, leading
zero bits between the two operands.

llvm-svn: 224849

ValueTracking: Small cleanup in ComputeNumSignBits

Constant contains the isAllOnesValue and isNullValue predicates, not
ConstantInt.

llvm-svn: 224848

InstCombe: Infer nsw for multiplies

We already utilize this logic for reducing overflow intrinsics, it makes
sense to reuse it for normal multiplies as well.

llvm-svn: 224847

Teach disassembler to handle illegal immediates on (v)cmpps/pd/ss/sd instructions. Instead of rejecting we'll just generate the _alt forms that don't try to alter the mnemonic. While I'm here, merge some common code in the Instruction printers for the condition code replacement and fix the mask on SSE to be 3-bits instead of 4.

llvm-svn: 224846

Use MCPhysReg for table of register encodings.

llvm-svn: 224845

Sema: Qualify getPrintable's Expr argument

getPrintable has an overload which takes a bool.  This means that const
qualified Exprs would get forwarded to the bool overload instead of the
Expr overload.

llvm-svn: 224844

WIP

llvm-svn: 224843

[PowerPC] [FastISel] i1 constants must be zero extended

When materializing constant i1 values, they must be zero extended. We represent
i1 values as [0, 1], not [0, -1], in i32 registers. As it turns out, this code
path was dead for i1 values prior to r216006 (which is why this did not manifest in
miscompiles until recently).

Fixes -O0 self-hosting on PPC64/Linux.

llvm-svn: 224842

[sanitizer] Tweak sancov.py output.

llvm-svn: 224841

[sanitizer] sancov.py: print status to stderr

llvm-svn: 224840

[asan] Disable __sanitizer_cov_dump registration on Windows.

Looks like we can't use atexit() during ASan initialization on Windows.

llvm-svn: 224839

[asan] Allow enabling coverage at activation.

llvm-svn: 224838

Simplify allocator_returns_null.cc test

llvm-svn: 224837

Initialize BackendConsumer::Context in constructor.

llvm-svn: 224836

Initialize CodeGeneratorImpl::Ctx in constructor.

llvm-svn: 224835

tsan: fix trace initialization during thread id reuse

The current code leaves the first event in the trace part uninitialized
(from the previous thread). It can cause unpredictable behavior
during stack/mutexset restoration.
Initialize the first event to a fake harmless memory access.

llvm-svn: 224834

Silence GCC's -Wparentheses warning

No functionality change intended.

llvm-svn: 224833