llvm-svn: 330171

We don't really care about the order as this is a dictionary.
It should be more resilient to changes (adding/shuffling stats
around).

Pointed out by Jason Molenda in a post-commit review (thanks Jason).

llvm-svn: 330170

Currently, the interaction between the triple, the CPU, and the
supported features is a mess: the driver edits the triple to indicate
the supported architecture version, and the LLVM backend uses this to
figure out what instructions are legal.  This makes it difficult to
understand what's happening, and makes it impossible to LTO together two
modules with different computed architectures.

Instead of relying on triple rewriting to get the correct target
features, we should add the right target features explicitly.

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

llvm-svn: 330169

Apparently, DebugInfoFinder::processCompileUnit doesn't process all
of the possible kinds of DIImportedEntit'ies, e.g. DIGlobalVariable's.

Previously introduced `llvm_unreachable` is therefore incorrect.
Removing it here.

llvm-svn: 330167

Summary:
There are some functions/methods that run when the application launches
or the library loads. Those functions will run reguardless the OS
version as long as it satifies the minimum deployment target. Annotate
them with availability attributes doesn't really make sense because they
are essentially available on all targets since minimum deployment
target.

rdar://problem/36093384

Reviewers: arphaman, erik.pilkington

Reviewed By: erik.pilkington

Subscribers: erik.pilkington, cfe-commits

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

llvm-svn: 330166

The API is `SBStructuredData GetStatistics()`. This allows
the command to be used in scripts.

<rdar://problem/36555975>

llvm-svn: 330165

This is causing large numbers of Chromium test executables to crash on
shutdown. The relevant symbol seems to be __cxa_finalize, which gets
removed from the dynamic symbol table for some of the support libraries.

llvm-svn: 330164

Bug: https://bugs.llvm.org/show_bug.cgi?id=36430

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

llvm-svn: 330163

This is basically part 2 of r313694.

It's a little unfortunate that I had to copy-paste atomic_support.h,
but I don't really see any alternative.

The refstring.h changes are the same as the libcxx changes in r313694.

llvm-svn: 330162

This reverts SVN r330158.

Seems that there was a change to linker flags handling in SVN r316972.
That would alter the behaviour to correct the linker flag handling in
CMake (requiring CMake 3.4.3+).  Since that is already the minimum
version required for LLVM, hard coding the knowledge of the linker is
not required, which is a strictly better solution.

llvm-svn: 330161

As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033
Any usage of a builtin function that uses a va_list by reference
will cause an assertion when redeclaring it.

After discussion in the review, it was concluded that the correct
way of accomplishing this fix is to make attempts to redeclare certain
builtins an error. Unfortunately, doing this limitation for all builtins
is likely a breaking change, so this commit simply limits it to
types with custom type checking and those that take a reference.

Two tests needed to be updated to make this work.

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

llvm-svn: 330160

Defer adding keywords to the identifier table until after the language options have been loaded from the AST file.

This fixes issues with "class" being reported as an identifier in "enum class" because the construct is not present when using default language options.

Patch by Johann Klähn.

llvm-svn: 330159

When building out-of-tree compilers (e.g. swift), the linker check here
may yield incorrect values.  Ensure that we are using lld before we
attempt to use `--color-diagnostics` for the linker.  Other linkers (i.e
bfd, gold) do not support this flag and the test can pass in some cases
and then fail subsequently when building.

llvm-svn: 330158

Using Config->is64() will treat ARM64 as Amd64, which is incorrect.
Furthermore, there are more esoteric architectures that could
theoretically be encountered.  Just set it directly to the machine
type, which we already know anyway.

llvm-svn: 330157

Global variables marked as declare target are allowed to be used in map
clauses. Patch fixes the crash of the compiler on the declare target
variables in map clauses.

llvm-svn: 330156

volatile array field is copied.

The crash occurs because method 'visitArray' passes a null FieldDecl to
method 'visit' and some of the methods called downstream expect a
non-null FieldDecl to be passed.

This reapplies r330151 with a fix to the test case.

rdar://problem/33599681

llvm-svn: 330155

llvm-svn: 330154

This reverts commit r330151, which caused bots to fail.

llvm-svn: 330153

framework module SomeKitCore {
  ...
  export_as SomeKit
}

Given the module above, while generting autolink information during
codegen, clang should to emit '-framework SomeKitCore' only if SomeKit
was not imported in the relevant TU, otherwise it should use '-framework
SomeKit' instead.

rdar://problem/38269782

llvm-svn: 330152

volatile array field is copied.

The crash occurs because method 'visitArray' passes a null FieldDecl to
method 'visit' and some of the methods called downstream expect a
non-null FieldDecl to be passed.

rdar://problem/33599681

llvm-svn: 330151

llvm-svn: 330150

llvm-svn: 330149

Summary:
Specifying assert message with an || operator makes the compiler interpret it
 as a bool. Changed it to &&.

Reviewers: asb, apazos

Reviewed By: asb

Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, llvm-commits

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

llvm-svn: 330148

In preparation for using it in the API.

<rdar://problem/36555975>

llvm-svn: 330147

Summary:
It looks like OSX's UBSan needs a "NoHooks" version of
`RTSanitizerCommonSymbolizer` to work build properly.

Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 330146

This fixes the failing tests.  They simply hadn't been updated
to match the new output resulting from this patch.

llvm-svn: 330145

This makes the test similar to the arith-sub.ll and arith-mul.ll tests.

llvm-svn: 330144

We use getExtractWithExtendCost to calculate the cost of extractelement and
s|zext together when computing the extract cost after vectorization, but we
calculate the cost of extractelement and s|zext separately when computing the
scalar cost which is larger than it should be.

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

llvm-svn: 330143

materializing function definitions.

MaterializationUnit instances are responsible for resolving and finalizing
symbol definitions when their materialize method is called. By contract, the
MaterializationUnit must materialize all definitions it is responsible for and
no others. If it can not materialize all definitions (because of some error)
then it must notify the associated VSO about each definition that could not be
materialized. The MaterializationResponsibility class tracks this
responsibility, asserting that all required symbols are resolved and finalized,
and that no extraneous symbols are resolved or finalized. In the event of an
error it provides a convenience method for notifying the VSO about each
definition that could not be materialized.

llvm-svn: 330142

notifyMaterializationFailed.

The notifyMaterializationFailed method can determine which error to raise by
looking at which queue the pending queries are in (resolution or finalization).

llvm-svn: 330141

llvm-svn: 330140

It was turned on for testing and was accidentally left on in the commit.

llvm-svn: 330139

Move veriication check for legal conversions to f128 into LowerINT_TO_FP()
and fix some indentations to match other sections of the code for readability.

llvm-svn: 330138

llvm-svn: 330137

[Attributes] Fix a bug in AttributeList::get so it can handle a mix of FunctionIndex and ReturnIndex/arg indices at the same time

The code uses the index of the last element in the sorted array to determine the maximum size needed for the vector. But if the last index is a FunctionIndex(~0), attrIdxToArrayIdx will return 0 and the vector will have size 1. If there are any indices before FunctionIndex, those values would return a value larger than 0 from attrIdxToArrayIdx. So in this case we need to look in front of the FunctionIndex to get the true size needed.

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

llvm-svn: 330136

If a class's first data member is an instance of an empty class, then an
assertion in the PrettyClassLayoutGraphicalDumper would fail. The
storage is reserved, but it's not marked as in use.

As far as I understand, it's the assertion that's faulty, so I removed it
and updated the nearby comment.

Found by running llvm-pdbutil against its own PDB, and this assertion would
fail on HashAdjusters, which is a HashTable whose first data member is a
TraitsT, which is a PdbHashTraits<T>, which is an empty struct. (The struct
has a specialization for uint32_t, but that specialization doesn't apply
here because the T is actually ulittle32_t.)

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

llvm-svn: 330135

Summary: Adding a couple missed RTSanitizerCommonSymbolizer in makefiles.

Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 330134

There are a couple of failing tests which slipped under my radar
so I'm reverting this while I attempt to fix.

llvm-svn: 330133

When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code.  This initial support only
handles standard thunk ordinals.

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

llvm-svn: 330132

Summary:
Host symbolizer & stacktraces related code in their own RT:
`RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer &
stacktraces specific code that used to live in common files is moved to a new
file `sanitizer_symbolizer_report.cc` as is.

The purpose of this is the enforce a separation between code that relies on
symbolization and code that doesn't. This saves the inclusion of spurious code
due to the interface functions with default visibility, and the extra data
associated.

The following sanitizers makefiles were modified & tested locally:
- dfsan: doesn't require the new symbolizer RT
- esan: requires it
- hwasan: requires it
- lsan: requires it
- msan: requires it
- safestack: doesn't require it
- xray: doesn't require it
- tsan: requires it
- ubsan: requires it
- ubsan_minimal: doesn't require it
- scudo: requires it (but not for Fuchsia that has a minimal runtime)

This was tested locally on Linux, Android, Fuchsia.

Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr

Reviewed By: alekseyshl, vitalybuka

Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 330131