This reverts commit 37e69667f748e1458b46483b7c1b8f9ba33eec44.

We're going to discuss its ramifications further before making a
conclusion.

llvm-svn: 320747

Rather than adding more bits to express every
MMO flag you could want, just directly use the
MMO flags. Also fixes using a bunch of bool arguments to
getMemIntrinsicNode.

On AMDGPU, buffer and image intrinsics should always
have MODereferencable set, but currently there is no
way to do that directly during the initial intrinsic
lowering.

llvm-svn: 320746

Summary:
The initial implementation used an ASan like Chunk class that was deriving from
a Header class. Due to potential races, we ended up working with local copies
of the Header and never using the parent class fields. ScudoChunk was never
constructed but cast, and we were using `this` as the pointer needed for our
computations. This was meh.

So we refactored ScudoChunk to be now a series of static functions within the
namespace `__scudo::Chunk` that take a "user" pointer as first parameter (former
`this`). A compiled binary doesn't really change, but the code is more sensible.

Clang tends to inline all those small function (in -O2), but GCC left a few not
inlined, so we add the `INLINE` keyword to all.

Since we don't have `ScudoChunk` pointers anymore, a few variables were renamed
here and there to introduce a clearer distinction between a user pointer
(usually `Ptr`) and a backend pointer (`BackendPtr`).

Reviewers: alekseyshl, flowerhack

Reviewed By: alekseyshl

Subscribers: #sanitizers, llvm-commits

Differential Revision: https://reviews.llvm.org/D41200

llvm-svn: 320745

llvm-svn: 320744

Clang-format categorizes and sorts #includes with style. It doesn't make sense
to manually managing #include blocks.

llvm-svn: 320743

Summary:
This change lays the groundwork lowering of @llvm.global_ctors
and @llvm.global_dtors for the wasm object format.  Some parts
of this patch are subset of: https://reviews.llvm.org/D40759

See https://github.com/WebAssembly/tool-conventions/issues/25

Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish

Differential Revision: https://reviews.llvm.org/D41208

llvm-svn: 320742

Subscribers: aheejin, llvm-commits

Differential Revision: https://reviews.llvm.org/D41255

llvm-svn: 320741

Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.

This part was initially developed inside libsanitizer in the GCC tree and should apply to
both.  Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.

I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.

Most of the changes are probably straightforward with a few exceptions:

* The Solaris syscall interface isn't stable, undocumented and can change within an
  OS release.  The stable interface is the libc interface, which I'm using here, if possible
  using the internal _-prefixed names.

* While the patch primarily target 32-bit x86, I've left a few sparc changes in.  They
  cannot currently be used with clang due to a backend limitation, but have worked
  fine inside the gcc tree.

* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
  Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.

The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11.  Only a few failures remain, some of them analyzed, some
still TBD:

    AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
    AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
    AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
    AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
    AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c

   SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
    SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations

Maybe this is good enough the get the ball rolling.

Reviewers: kcc, alekseyshl

Reviewed By: alekseyshl

Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D40898

llvm-svn: 320740

This reverts commit ac5edc198eb612f82293850c3488042708b1c5fa.

Apparently this doesn't cover all the bases, so some compilers
and standard libraries still think this is not trivially copyable
even though it is.  Reverting this back to an MSVC-only check for
now so that at least we have some coverage.

llvm-svn: 320739

llvm-svn: 320738

This should be a better check than using is_trivially_copyable
behind an #ifdef _MSC_VER.

llvm-svn: 320737

In SLPVectorizer, the vector build instructions (insertvalue for aggregate type) is passed to BoUpSLP.buildTree, it is treated as UserIgnoreList, so later in cost estimation, the cost of these instructions are not counted. 
For aggregate value, later usage are more likely to be done in scalar registers, either used as individual scalars or used as a whole for function call or return value. Ignore scalar extraction instructions may cause too aggressive vectorization for aggregate values, and slow down performance. So for vectorization of aggregate value, the scalar extraction instructions are required in cost estimation.

Differential Revision: https://reviews.llvm.org/D41139

llvm-svn: 320736

llvm-svn: 320735

builtin macros

This patch implements the __is_target_arch, __is_target_vendor, __is_target_os,
and __is_target_environment Clang preprocessor extensions that were proposed by
@compnerd in Bob's cfe-dev post:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html.

These macros can be used to examine the components of the target triple at
compile time. A has_builtin(is_target_???) preprocessor check can be used to
check for their availability.

__is_target_arch allows you to check if an arch is specified without worring
about a specific subarch, e.g.

__is_target_arch(arm) returns 1 for the target arch "armv7"
__is_target_arch(armv7) returns 1 for the target arch "armv7"
__is_target_arch(armv6) returns 0 for the target arch "armv7"

__is_target_vendor and __is_target_environment match the specific vendor
or environment. __is_target_os matches the specific OS, but
__is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be used
to test if the triple's component is specified.

rdar://35753116

Differential Revision: https://reviews.llvm.org/D41087

llvm-svn: 320734

Apparently this isn't present on older versions of libstdc++, so
it causes some builds to fail.

llvm-svn: 320733

Hexagon HVX has type v128i8, comparing two vectors of that type will
produce v128i1 types in SelectionDAG.

llvm-svn: 320732

This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).

Hopefully the Windows support is fixed now.

Patch by Rainer Orth!

Differential Revision: https://reviews.llvm.org/D40944

llvm-svn: 320731

Summary:
InterlockedCompareExchange128 is a bit more complicated than the other
InterlockedCompareExchange functions, so it requires a bit more work. It
doesn't directly refer to 128bit ints, instead it takes pointers to
64bit ints for Destination and ComparandResult, and exchange is taken as
two 64bit ints (high & low). The previous value is written to
ComparandResult, and success is returned. This implementation does the
following in order to produce a cmpxchg instruction:

  1. Cast everything to 128bit ints or int pointers, and glues together
     the Exchange values
  2. Reads from CompareandResult to get the comparand
  3. Calls cmpxchg volatile (on X86 this will produce a lock cmpxchg16b
     instruction)
    1. Result 0 (previous value) is written back to ComparandResult
    2. Result 1 (success bool) is zext'ed to a uchar and returned

Resolves bug https://llvm.org/PR35251

Patch by Colden Cullen!

Reviewers: rnk, agutowski

Reviewed By: rnk

Subscribers: majnemer, cfe-commits

Differential Revision: https://reviews.llvm.org/D41032

llvm-svn: 320730

llvm-svn: 320729

This reverts commit r320726. It looks like flock isn't available on
Windows:

http://lab.llvm.org:8011/builders/sanitizer-windows/builds/21317/steps/build%20compiler-rt/logs/stdio

llvm-svn: 320728

llvm-svn: 320727

This includes a few nice bits of refactoring (e.g splitting out the
exclusive locking code into a common utility).

Patch by Rainer Orth!

Differential Revision: https://reviews.llvm.org/D40944

llvm-svn: 320726

This is a Swift feature.  The output stream for the index page and the source
HTML page is utf-8 now.

The next patch will add the HTML magic to properly render these characters in
the browser.

llvm-svn: 320725

Newer versions of CMake (I'm on 3.10, but I believe 3.9 behaves the same
way) attempt to query the system for information about the VS 2017
install. Unfortunately, this query fails on non-Windows systems:

  cmake_host_system_information does not recognize <key> VS_15_DIR

CMake isn't going to find these system libraries on non-Windows anyway
(and we were previously silencing the resultant warnings in our
cross-compilation toolchain), so it makes sense to just omit the
attempted installation entirely on non-Windows.

Differential Revision: https://reviews.llvm.org/D41220

llvm-svn: 320724

This doesn't match the semantics of the extract_vector_elt operation. Nothing downstream knows the bits were zeroed so they still get masked or sign extended after the extrat anyway.

llvm-svn: 320723

HVX does not support operations on 64-bit integers.

llvm-svn: 320722

the lambda so that we don't over-release it.

Patch by Dan Zimmerman!

llvm-svn: 320721

While I'm pushing cleanup changes, this also fixes a few warnings
related to extraneous semicolons.

llvm-svn: 320720

This adds the /DEBUG:GHASH option to LLD which will look for
the existence of .debug$H sections in linker inputs and use them
to accelerate type merging.  The clang-cl side has already been
added, so this completes the work necessary to begin experimenting
with this feature.

Differential Revision: https://reviews.llvm.org/D40980

llvm-svn: 320719

Fixes expensive-check ARM buildbot failure.

llvm-svn: 320718

Added codegen for the `nowait` clause in target data constructs.

llvm-svn: 320717

NFC.
Adding MC regressions tests to cover the AVX and AVX2 ISA sets.
This patch is part of a larger task to cover MC encoding of all X86 ISA Sets.
See revision: https://reviews.llvm.org/D39952

Reviewers: zvi, RKSimon, aymanmus, m_zuckerman
Differential Revison: https://reviews.llvm.org/D40287

Change-Id: I304687a2b7abb473f79de99c31fc55c97b2662da
llvm-svn: 320716

llvm-svn: 320715

Summary:
If we write the following code, it goes over 100 columns, so we need to wrap it:

```
- (VeryLongReturnTypeName)veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
                              longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

Currently, clang-format with the google style aligns the method parameter names on the first column:

```
- (VeryLongReturnTypeName)
veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
    longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

We'd like clang-format in the google style to align these to column 4 for Objective-C:

```
- (VeryLongReturnTypeName)
    veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
            longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: krasimir, djasper, klimek

Reviewed By: djasper

Subscribers: cfe-commits, thakis

Differential Revision: https://reviews.llvm.org/D41195

llvm-svn: 320714

Supports a comma-separated list of check names to be disabled on the given line. Also supports * as a wildcard to disable all lint diagnostic messages on that line.

Patch by Anton (xgsa).

llvm-svn: 320713

This commit might have caused regression on ppc64. Revert it to verify that.

llvm-svn: 320712

Summary:
The generated diagnostic by the AsmMatcher isn't always applicable to the AsmOperand.

This is because the code will only update the diagnostic if it is more 
specific than the previous diagnostic. However, when having validated
operands and 'moved on' to a next operand (for some instruction/alias for
which all previous operands are valid), if the diagnostic is InvalidOperand,
than that should be set as the diagnostic, not the more specific message
about a previous operand for some other instruction/alias candidate.

(Re-committed with an extra whitespace in SVEInstrFormats.td to trigger rebuild 
of AArch64GenAsmMatcher.inc, since the llvm-clang-x86_64-expensive-checks-win
builder does not seem to rebuild AArch64GenAsmMatcher.inc with the
newly built TableGen due to a missing dependency somewhere (see:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119555.html))

Reviewers: craig.topper, olista01, rengolin, stoklund

Reviewed By: olista01

Subscribers: javed.absar, llvm-commits

Differential Revision: https://reviews.llvm.org/D40011

llvm-svn: 320711

Differential revision: https://reviews.llvm.org/D41238

llvm-svn: 320710

update the type from the definition even if we didn't instantiate a definition.

We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.

llvm-svn: 320709

Summary:
EventTracer interface now contains two methods:
- spanEvent for events that have duration,
- instant for events that are instant.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, luckygeck, cfe-commits

Differential Revision: https://reviews.llvm.org/D40489

llvm-svn: 320708