Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.

Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.

Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.

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

llvm-svn: 315590

This is a follow-up suggested in D37534.
Patch by Yulia Koval.

llvm-svn: 315589

The number 131076 didn't show up anywhere in the test.

llvm-svn: 315588

[X86][SSE] Pull out repeated INSERT_VECTOR_ELT code from LowerBUILD_VECTOR v16i8/v8i16 insertion. NFCI.

llvm-svn: 315587

function params.

Codegen could crash if the array section base expression is the
function parameter.

llvm-svn: 315586

The address of the .got section is not relevant for the test.

llvm-svn: 315585

It doesn't make sense to link from an alloc section to a non alloc
one as we were doing.

This matches the behavior of both gold and bfd.

llvm-svn: 315584

Summary:
This first part just prepares the grounds for part 2 and doesn't add any new
functionality. It mostly consists of small refactors:
- move the `pthread.h` include higher as it will be used in the headers;
- use `errno.h` in `scudo_allocator.cpp` instead of the sanitizer one, update
  the `errno` assignments accordingly (otherwise it creates conflicts on some
  platforms due to `pthread.h` including `errno.h`);
- introduce and use `getCurrentTSD` and `setCurrentTSD` for the shared TSD
  model code;

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: llvm-commits, srhines

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

llvm-svn: 315583

llvm-svn: 315582

The typo in r315556 disabled the cfi-verify unit tests from building
unconditionally, have it correctly check for the X86 target.

llvm-svn: 315581

This reverts r315057. The revision introduces assertion failures:
assertion failed at llvm/tools/clang/include/clang/Basic/SourceManager.h:428 in
const clang::SrcMgr::ExpansionInfo &clang::SrcMgr::SLocEntry::getExpansion()
const: isExpansion() && "Not a macro expansion SLocEntry!"
Stack trace:
    __assert_fail
    clang::SrcMgr::SLocEntry::getExpansion()
    clang::SourceManager::getExpansionLocSlowCase()
    clang::SourceManager::getExpansionLoc()
    clang::Lexer::getRawToken()
    clang::tidy::readability::NamespaceCommentCheck::check()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::MatchVisitor::visitMatch()
    clang::ast_matchers::internal::BoundNodesTreeBuilder::visitMatches()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchWithFilter()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::matchDispatch()
    clang::ast_matchers::internal::(anonymous namespace)::MatchASTVisitor::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::RecursiveASTVisitor<>::TraverseDeclContextHelper()
    clang::RecursiveASTVisitor<>::TraverseDecl()
    clang::ast_matchers::MatchFinder::matchAST()
    clang::MultiplexConsumer::HandleTranslationUnit()
    clang::ParseAST()
    clang::FrontendAction::Execute()
    clang::CompilerInstance::ExecuteAction()
    clang::tooling::FrontendActionFactory::runInvocation()
    clang::tooling::ToolInvocation::runInvocation()
    clang::tooling::ToolInvocation::run()

Still working on an isolated test case.

llvm-svn: 315580

MachineInstr::isIdenticalTo has a lot of logic for dealing with register
Defs (i.e. deciding whether to take them into account or ignore them).
This logic gets things wrong in some obscure cases, for instance if an
operand is not a Def for both the current MI and the one we are
comparing to.

I'm not sure if it's possible for this to happen for regular register
operands, but it may happen in the ARM backend for special operands
which use sentinel values for the register (i.e. 0, which is neither a
physical register nor a virtual one).

This causes MachineInstrExpressionTrait::isEqual (which uses
MachineInstr::isIdenticalTo) to return true for the following
instructions, which are the same except for the fact that one sets the
flags and the other one doesn't:
%1114 = ADDrsi %1113, %216, 17, 14, _, def _
%1115 = ADDrsi %1113, %216, 17, 14, _, _

OTOH, MachineInstrExpressionTrait::getHashValue returns different values
for the 2 instructions due to the different isDef on the last operand.
In practice this means that when trying to add those instructions to a
DenseMap, they will be considered different because of their different
hash values, but when growing the map we might get an assertion while
copying from the old buckets to the new buckets because isEqual
misleadingly returns true.

This patch makes sure that isEqual and getHashValue agree, by improving
the checks in MachineInstr::isIdenticalTo when we are ignoring virtual
register definitions (which is what the Trait uses). Firstly, instead of
checking isPhysicalRegister, we use !isVirtualRegister, so that we cover
both physical registers and sentinel values. Secondly, instead of
checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo,
which checks isReg, isSubReg and isDef, which are the same values that
the hash function uses to compute the hash.

Note that the function is symmetric with this change, since if the
current operand is not a Def, we check MachineOperand::isIdenticalTo,
which returns false if the operands have different isDef's.

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

llvm-svn: 315579

in C.

If we try to get the lvalue for thread_id variables in inlined regions,
we did not use the correct version of function. Fixed this bug by adding
overrided version of the function getThreadIDVariableLValue for inlined
regions.

llvm-svn: 315578

Summary:
Make the ProtocolHandlers glue between JSONRPCDispatcher and
ClangdLSPServer generic.
Eliminate small differences between methods, de-emphasize the unimportant
distinction between notifications and methods.

ClangdLSPServer is no longer responsible for producing a complete
JSON-RPC response, just the JSON of the result object. (In future, we
should move that JSON serialization out, too).
Handler methods now take a context object that we may hang more
functionality off in the future.

Added documentation to ProtocolHandlers.

Reviewers: ilya-biryukov, bkramer

Reviewed By: ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 315577

While this shouldn't be necessary anymore, we have cases where we run
into the assertion below, i.e. cases with two non-fragment entries for the
same variable at different frame indices.

This should be fixed, but for now, we should revert to a version that
does not trigger asserts.

llvm-svn: 315576

This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial ways. Eventually, we will consider each of these
cases to make sure the TBAA information is correct and not too
conservative. For now, we just fall back to generating TBAA info
from the access type.

This patch should not bring in any functional changes.

This is part of D38126 reworked to be a separate patch to
simplify review.

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

llvm-svn: 315575

Restore the file extension. Make the namespace longer than the
ShortNamespaceLines so that the check triggers.

llvm-svn: 315574

llvm-svn: 315573

SVal::getAsSymbol(bool IncludeBaseRegions): Follow clang/StaticAnalyzer/Core/PathSensitive/SVals.h, s/IncludeBaseRegion/IncludeBaseRegions/g [-Wdocumentation]

llvm-svn: 315572

This fixes the "switch statement contains 'default' but no 'case' labels"
warnings in table-generated code introduced in r315295.

llvm-svn: 315571

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

llvm-svn: 315570

Previously we did not support following:
foo = ~0xFF;
and had to add space before numeric value:
foo = ~ 0xFF

That was constistent with ld.bfd < 2.30, which shows:
script.txt:3: undefined symbol `~2' referenced in expression,
but inconsistent with gold.

It was fixed for ld.bfd 2.30 as well:
https://sourceware.org/bugzilla/show_bug.cgi?id=22267

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

llvm-svn: 315569

llvm-svn: 315568

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

llvm-svn: 315567

clang/module.modulemap: Create Clang_Frontend_CodeGenOptions to remove some dependencies in clangBasic.

- Clang_Analysis
- Clang_C
- Clang_Frontend
- Clang_Lex
- Clang_Sema
- Clang_Serialization
- Clang_StaticAnalyzer_Core

llvm-svn: 315566

[ScheduleDAGInstrs] fix behavior of getUnderlyingObjectsForCodeGen when no identifiable object found

This patch fixes the bug introduced in https://reviews.llvm.org/D35907; the bug is reported by http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171002/491452.html.

Before D35907, when GetUnderlyingObjects fails to find an identifiable object, allMMOsOkay lambda in getUnderlyingObjectsForInstr returns false and Objects vector is cleared. This behavior is unintentionally changed by D35907.

This patch makes the behavior for such case same as the previous behavior.
Since D35907 introduced a wrapper function getUnderlyingObjectsForCodeGen around GetUnderlyingObjects, getUnderlyingObjectsForCodeGen is modified to return a boolean value to ask the caller to clear the Objects vector.

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

llvm-svn: 315565

Summary:
The comments in the code said

 // Remove <def,read-undef> flags. This def is now a partial redef.

but the code didn't just remove read-undef, it could introduce new ones which
could cause errors.

E.g. if we have something like

%vreg1<def> = IMPLICIT_DEF
%vreg2:subreg1<def, read-undef> = op %vreg3, %vreg4
%vreg2:subreg2<def> = op %vreg6, %vreg7

and we merge %vreg1 and %vreg2 then we should not set undef on the second subreg
def, which the old code did.

Now we solve this by actually do what the code comment says. We remove
read-undef flags rather than remove or introduce them.

Reviewers: qcolombet, MatzeB

Reviewed By: MatzeB

Subscribers: llvm-commits

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

llvm-svn: 315564

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

llvm-svn: 315563

GNU ld automatically exports all symbols if no symbols have
been chosen to export via either def files or dllexport attributes.
The same behaviour can also be enabled via the GNU ld option
--export-all-symbols, in case some symbols are marked for export
via a def file or dllexport attribute.

The list of excluded symbols is from GNU ld, minus the
cygwin specific symbols.

Also add support for outputting the actual list of exported
symbols in a def file, as in the GNU ld option --output-def.

These options in GNU ld are documented in
https://sourceware.org/binutils/docs/ld/WIN32.html.

This currently exports all symbols from object files pulled in
from libmingw32 and libmingwex and other static libraries
that are linked in.

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

llvm-svn: 315562

This is implemented in the same way as the other ADDR32NB relocations
for ARM and X64.

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

llvm-svn: 315561

adjustExpr became a mysterious function as it does too many things.
This patch is an attempt to destructure that function.

llvm-svn: 315560

llvm-svn: 315559

llvm-svn: 315558

Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer=aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer=x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.

Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.

This re-applies 315545 using "=" instead of ":" as a separator for
arguments.

llvm-svn: 315557

The llvm-cfi-verify unit tests fail if LLVM is built without the X86
target, disable the unit tests from being built unless X86 is enabled
for now.

llvm-svn: 315556

llvm-svn: 315555

It broke some tests on Windows:

Failing Tests (4):
    LLVM :: tools/llvm-isel-fuzzer/execname-options.ll
    LLVM :: tools/llvm-isel-fuzzer/missing-triple.ll
    LLVM :: tools/llvm-isel-fuzzer/x86-empty-bc.ll
    LLVM :: tools/llvm-isel-fuzzer/x86-empty.ll

> llvm-isel-fuzzer: Handle a subset of backend flags in the executable name
>
> Here we add a secondary option parser to llvm-isel-fuzzer (and provide
> it for use with other fuzzers). With this, you can copy the fuzzer to
> a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
> AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
> flags required. This should be useful for running these in OSS-Fuzz.
>
> Note that this handrolls a subset of cl::opts to recognize, rather
> than embedding a complete command parser for argv[0]. If we find we
> really need the flexibility of handling arbitrary options at some
> point we can rethink this.

llvm-svn: 315554

The SanitizerCommon.ReservedAddressRangeUnmap test fails on Windows:

FAIL: SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap (34003 of 35554)
******************** TEST 'SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap' FAILED ********************
Note: Google Test filter = SanitizerCommon.ReservedAddressRangeUnmap
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SanitizerCommon
[ RUN      ] SanitizerCommon.ReservedAddressRangeUnmap
==3780==ERROR: SanitizerTool failed to deallocate 0x1000 (4096) bytes at address 0x0000000c3000 (error code: 487)
==3780==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:129 (("unable to unmap" && 0)) != (0) (0, 0)
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 299.76s
********************
Failing Tests (1):
    SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap

> In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
> VMAR, which means that MmapNoAccess can only be called once. This works
> for the sanitizer allocator but *not* for the Scudo allocator.
>
> Hence, this changeset introduces a new ReservedAddressRange object to
> serve as the new API for these calls. In this changeset, the object
> still calls into the old Mmap implementations.
>
> The next changeset two changesets will convert the sanitizer and scudo
> allocators to use the new APIs, respectively. (ReservedAddressRange will
> replace the SecondaryHeader in Scudo.)
>
> Finally, a last changeset will update the Fuchsia implementation.
>
> Patch by Julia Hansbrough
>
> Differential Revision: https://reviews.llvm.org/D38437

llvm-svn: 315553

A section was passed to getRelExpr just to create an error message.
But if there's an invalid relocation, we would eventually report it
in relocateOne. So we don't have to pass a section to getRelExpr.

llvm-svn: 315552

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

llvm-svn: 315551