LLVM/llvm 351793clang-tools-extra/trunk/clangd ClangdUnit.cpp Compiler.cpp

[clangd] NFC: Use buildCompilerInvocation in CodeComplete

Reviewers: ilya-biryukov, sammccall

Reviewed By: sammccall

Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits

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

LLVM/llvm 351792clang-tools-extra/trunk/clangd ClangdUnit.cpp ClangdServer.h, clang-tools-extra/trunk/clangd/tool ClangdMain.cpp

[clangd] Support clang-tidy configuration in clangd.

Summary:
This patch adds some basic supports for clang-tidy configurations in clangd:
      - clangd will respect .clang-tidy configurations for each file
      - we don't aim to support all clang-tidy options in clangd, only a
        small subset of condfigurations (options related to which checks will be
        enabled) are supported.
      - add a `clang-tidy-checks` CLI option that can override options from
        .clang-tidy file

Reviewers: ilya-biryukov, sammccall

Reviewed By: sammccall

Subscribers: javed.absar, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

LLVM/llvm 351791llvm/trunk/include/llvm/Analysis GuardUtils.h, llvm/trunk/lib/Analysis GuardUtils.cpp

[NFC] Add detector for guards expressed as branch by widenable conditions

This patch adds a function to detect guards expressed in explicit control
flow form as branch by `and` with widenable condition intrinsic call:

    %wc = call i1 @llvm.experimental.widenable.condition()
    %guard_cond = and i1, %some_cond, %wc
    br i1 %guard_cond, label %guarded, label %deopt

  deopt:
    <maybe some non-side-effecting instructions>
    deoptimize()

This form can be used as alternative to implicit control flow guard
representation expressed by `experimental_guard` intrinsic.

Differential Revision: https://reviews.llvm.org/D56074
Reviewed By: reames

LLVM/llvm 351790lld/trunk/test/ELF as-needed-weak.s icf-symbol-type.s, lld/trunk/test/ELF/linkerscript provide-shared2.s

[LLD][ELF]Fix tests for D56910

r351789 changes the output of llvm-readelf --dyn-symbols. This causes 3
LLD tests to break. This patch fixes them.

Reviewed by: ruiu

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

LLVM/llvm 351789llvm/trunk/test/tools/llvm-readobj gnu-hash-symbols.test gnu-symbols.test, llvm/trunk/tools/llvm-readobj ELFDumper.cpp llvm-readobj.cpp

[llvm-readelf]Revert --dyn-symbols behaviour to make it GNU compatible, and add new 
--hash-symbols switch for old behaviour

In r287786, the behaviour of --dyn-symbols in llvm-readelf (but not
llvm-readobj) was changed to print the dynamic symbols as derived from
the hash table, rather than to print the dynamic symbol table contents
directly. The original change was initially submitted without review,
and some comments were made on the commit mailing list implying that the
new behavious is GNU compatible. I argue that it is not:

  1) It does not include a null symbol.
  2) It prints the symbols based on an order derived from the hash
     table.
  3) It prints an extra column indicating which bucket it came from.
     This could break parsers that expect a fixed number of columns,
     with the first column being the symbol index.
  4) If the input happens to have both .hash and .gnu.hash section, it
     prints interpretations of them both, resulting in most symbols
     being printed twice.
  5) There is no way of just printing the raw dynamic symbol table,
     because --symbols also prints the static symbol table.

This patch reverts the --dyn-symbols behaviour back to its old behaviour
of just printing the contents of the dynamic symbol table, similar to
what is printed by --symbols. As the hashed interpretation is still

    [16 lines not shown]

LLVM/llvm 351788clang-tools-extra/trunk/clangd GlobalCompilationDatabase.cpp ClangdServer.cpp, clang-tools-extra/trunk/clangd/index Background.cpp

[clangd] Filter out plugin related flags and move all commandline manipulations into 
OverlayCDB.

Summary:
Some projects make use of clang plugins when building, but clangd is
not aware of those plugins therefore can't work with the same compile command
arguments.

There were multiple places clangd performed commandline manipulations,
 this one also moves them all into OverlayCDB.

Reviewers: ilya-biryukov

Subscribers: klimek, sammccall, ioeric, MaskRay, jkorous, arphaman, cfe-commits

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

LLVM/llvm 351787zorg/trunk/zorg/buildbot/builders FuchsiaBuilder.py

[Fuchsia] Always clean-up the SDK directory

Avoid previous stale versions, use unzip with override.

LLVM/llvm 351786llvm/trunk/include/llvm/Support type_traits.h

Revert "Remove static_assert(value == std::is_trivially_copyable<T>::value)"

Upgraded the bot as workaround.

This reverts commit r351784.

LLVM/llvm 351785llvm/trunk/lib/Target/RISCV RISCVISelDAGToDAG.cpp

[RISCV][NFC] Add break to case statement in RISCVDAGToDAGISel::Select

The break isn't strictly needed yet as there is no subsequent entry in the
case. But adding to prevent mistakes further down the road.

LLVM/llvm 351784llvm/trunk/include/llvm/Support type_traits.h

Remove static_assert(value == std::is_trivially_copyable<T>::value)

This fails to compile with clang ang libstdc++ 4.6

LLVM/llvm 351783compiler-rt/trunk/lib/safestack safestack_platform.h safestack.cc

[safestack] Return syscalls for mmap, munmap and mprotect

This function can be already intercepted by instrumented code.

LLVM/llvm 351782llvm/trunk/lib/Target/RISCV RISCVISelLowering.cpp

[RISCV] Fix build after r351778

Also add a comment to explain the expansion strategy for atomicrmw
{fadd,fsub}.

LLVM/llvm 351781lldb/trunk/lit/SymbolFile/Breakpad symtab.test, lldb/trunk/lit/SymbolFile/Breakpad/Inputs symtab.syms

breakpad: Add FUNC records to the symtab

This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.

To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.

Reviewers: clayborg, lemo, zturner

Reviewed By: clayborg

Subscribers: lldb-commits

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

LLVM/llvm 351780zorg/trunk/zorg/buildbot/builders FuchsiaBuilder.py

Only add one property WithProperties invocation

This is triggering a key error.

LLVM/llvm 351779lldb/trunk/lit/ExecControl/StopHook/Inputs stop-hook-2.lldbinit stop-hook-3.lldbinit, lldb/trunk/lit/Reproducer/Inputs GDBRemoteCapture.in

[Test] Fix up tests affected by the new LLVM header.

The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.

LLVM/llvm 351778llvm/trunk/lib/AsmParser LLParser.cpp, llvm/trunk/test/Transforms/AtomicExpand/AArch64 atomicrmw-fp.ll

IR: Add fp operations to atomicrmw

Add just fadd/fsub for now.

LLVM/llvm 351777zorg/trunk/buildbot/osuosl/master/config builders.py status.py, zorg/trunk/zorg/buildbot/builders FuchsiaBuilder.py

Added missing commas, removed excessive args.

LLVM/llvm 351776llvm/trunk/lib/Target/ARM ARMISelLowering.cpp, llvm/trunk/test/CodeGen/Thumb shift-and.ll

[ARM] Combine ands+lsls to lsls+lsrs for Thumb1.

This patch may seem familiar... but my previous patch handled the
equivalent lsls+and, not this case.  Usually instcombine puts the
"and" after the shift, so this case doesn't come up. However, if the
shift comes out of a GEP, it won't get canonicalized by instcombine,
and DAGCombine doesn't have an equivalent transform.

This also modifies isDesirableToCommuteWithShift to suppress DAGCombine
transforms which would make the overall code worse.

I'm not really happy adding a bunch of code to handle this, but it would
probably be tricky to substantially improve the behavior of DAGCombine
here.

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

LLVM/llvm 351775www/trunk/foundation/relicensing index.html

Add another company that signed.

LLVM/llvm 351774llvm/trunk/lib/Analysis LazyValueInfo.cpp, llvm/trunk/lib/Transforms/Scalar CorrelatedValuePropagation.cpp

[CVP] Use LVI to constant fold deopt operands

Deopt operands are generally intended to record information about a site in code with 
minimal perturbation of the surrounding code. Idiomatically, they also tend to appear down 
rare paths. Putting these together, we have an obvious case for extending CVP w/deopt 
operand constant folding. Arguably, we should be doing this for all operands on all 
instructions, but that's definitely a much larger and risky change.

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

LLVM/llvm 351773libcxx/trunk/www upcoming_meeting.html

Updated issue 3144

LLVM/llvm 351772llvm/trunk/docs LangRef.rst

[LangRef] Clarify semantics of volatile operations.

Specifically, clarify the following:

1. Volatile load and store may access addresses that are not memory.
2. Volatile load and store do not modify arbitrary memory.
3. Volatile load and store do not trap.

Prompted by recent volatile discussion on llvmdev.

Currently, there's sort of a split in the source code about whether
volatile operations are allowed to trap; this resolves that dispute in
favor of not allowing them to trap.

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

LLVM/llvm 351771compiler-rt/trunk/lib/interception interception_linux.cc

[safestack] Fix NetBSD build

LLVM/llvm 351770libcxx/trunk/www upcoming_meeting.html

Update with issues to be moved in San Diego

LLVM/llvm 351769llvm/trunk/lib/CodeGen MachineVerifier.cpp, llvm/trunk/test/Verifier test_g_add.mir test_g_trunc.mir

GlobalISel: Fix out of bounds crashes in verifier

LLVM/llvm 351768llvm/trunk/lib/Target/AArch64 AArch64InstrFormats.td, llvm/trunk/test/CodeGen/AArch64 shift-mod.ll

[AArch64] Add patterns for zext/sext of shift amount.

Not sure this is the best fix, but it saves an instruction for certain
constructs involving variable shifts.

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

LLVM/llvm 351767llvm/trunk/lib/Target/AMDGPU AMDGPULegalizerInfo.cpp, llvm/trunk/test/CodeGen/AMDGPU/GlobalISel legalize-uitofp.mir legalize-fptoui.mir

AMDGPU/GlobalISel: Legalize more fp<->int conversions

LLVM/llvm 351766cfe/trunk/lib/CodeGen CGExprConstant.cpp, cfe/trunk/test/CodeGen const-init.c

[CodeGen] Always use string computed in Sema for PredefinedExpr

We can't use any other string, anyway, because its type wouldn't
match the type of the PredefinedExpr.

With this change, we don't compute a "nice" name for the __func__ global
when it's used in the initializer for a constant. This doesn't seem like
a great loss, and I'm not sure how to fix it without either storing more
information in the AST, or somehow threading through the information
from ExprConstant.cpp.

This could break some situations involving BlockDecl; currently,
CodeGenFunction::EmitPredefinedLValue has some logic to intentionally
emit a string different from what Sema computed.  This code skips that
logic... but that logic can't work correctly in general anyway.  (For
example, sizeof(__func__) returns the wrong result.) Hopefully this
doesn't affect practical code.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40313 .

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

LLVM/llvm 351765llvm/trunk/cmake/modules CheckCompilerVersion.cmake, llvm/trunk/docs DeveloperPolicy.rst GettingStarted.rst

Document toolchain update policy

Summary:
Capture the current agreed-upon toolchain update policy based on the following
discussions:

  - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"
    llvm.org/devmtg/2018-10/talk-abstracts.html#bof3
  - A Short Policy Proposal Regarding Host Compilers
    lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html
  - Using C++14 code in LLVM (2018)
    lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html
  - Using C++14 code in LLVM (2017)
    lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html
  - Using C++14 code in LLVM (2016)
    lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html
  - Document and Enforce new Host Compiler Policy
    llvm.org/D47073
  - Require GCC 5.1 and LLVM 3.5 at a minimum
    llvm.org/D46723

Subscribers: jkorous, dexonsmith, llvm-commits

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

LLVM/llvm 351764llvm/trunk/test/CodeGen/X86 vector-partial-undef.ll

[x86] add another test for xor with undefs; NFC

LLVM/llvm 351763llvm/trunk/test/CodeGen/X86 vector-partial-undef.ll

[x86] add tests for vector ops with undef lanes; NFC

LLVM/llvm 351762llvm/trunk/lib/Target/X86 X86InstrAVX512.td X86ISelLowering.cpp

[X86] Use X86ISD::VFPROUND instead of ISD::FP_ROUND for 256 and 512 bit cvtpd2ps 
intrinsics.

Summary:
Use X86ISD::VFPROUND in the instruction isel patterns. Add new patterns for ISD::FP_ROUND 
to maintain support for fptrunc in IR.

In the process I found a couple duplicate isel patterns which I also deleted in this 
patch.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

LLVM/llvm 351761llvm/trunk/lib/Target/X86 X86InstrAVX512.td X86ISelLowering.cpp

[X86] Change avx512 COMPRESS and EXPAND lowering to use a single masked node instead of 
expand/compress+select.

Summary:
For compress, a select node doesn't semantically reflect the behavior of the instruction. 
The mask would have holes in it, but the resulting write is to contiguous elements at the 
bottom of the vector.

Furthermore, as far as the compressing and expanding is concerned the behavior is depended 
on the mask. You can't just have an expand/compress node that only reads the input vector. 
That node would have no meaning by itself.

This all only works because we pattern match the compress/expand+select back to the 
instruction. But conceivably an optimization of the select could break the pattern and 
leave something meaningless.

This patch modifies the expand and compress node to take the mask and passthru as 
additional inputs and gets rid of the select all together.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

LLVM/llvm 351760lldb/trunk/lit/SymbolFile/NativePDB function-types-classes.cpp

Fix test after AST dump output change

LLVM/llvm 351759llvm/trunk/lib/Target/AMDGPU GCNHazardRecognizer.cpp GCNHazardRecognizer.h, llvm/trunk/test/CodeGen/AMDGPU vmem-vcc-hazard.mir

[AMDGPU] Fixed hazard recognizer to walk predecessors

Fixes two problems with GCNHazardRecognizer:
1. It only scans up to 5 instructions emitted earlier.
2. It does not take control flow into account. An earlier instruction
from the previous basic block is not necessarily a predecessor.
At the same time a real predecessor block is not scanned.

The patch provides a way to distinguish between scheduler and
hazard recognizer mode. It is OK to work with emitted instructions
in the scheduler because we do not really know what will be emitted
later and its order. However, when pass works as a hazard recognizer
the schedule is already finalized, and we have full access to the
instructions for the whole function, so we can properly traverse
predecessors and their instructions.

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

LLVM/llvm 351758llvm/trunk/utils/gn/build/libs/xml BUILD.gn

gn build: Stop passing -DLLVM_LIBXML2_ENABLED to some targets

This is a remnant from before the gn build had a working config.h.

Defining LLVM_LIBXML2_ENABLED only for targets that depend on build/libs/xml is
nice in that only some of the codebase needs to be rebuilt when
llvm_enable_libxml2 changes -- but config.h already defines it and defining it
there and then redundantly a second time for some targets is worse than having
it just in config.h.

No behavior change.

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

LLVM/llvm 351757llvm/trunk/utils/gn/secondary/llvm/lib/IR BUILD.gn, llvm/trunk/utils/gn/secondary/llvm/lib/Support BUILD.gn

gn build: Merge r351627, r351548, r351701

LLVM/llvm 351756llvm/trunk/unittests/ADT OptionalTest.cpp

Fix compilation error with gcc 4.8

This version of gcc seems to be having issues with raw literals inside macro
arguments. I change the string to use regular string literals instead.

LLVM/llvm 351755llvm/trunk/lib/Target/X86 X86ScheduleBtVer2.td, llvm/trunk/test/CodeGen/X86 mmx-schedule.ll

[X86][BtVer2] Update latency of mmx horizontal operations

D56777 added +1cy local forwarding penalty for horizontal operations, but this penalty 
only affects sse2/xmm variants, the mmx variants don't suffer the penalty.

Confirmed with @andreadb

LLVM/llvm 351754llvm/trunk/test/CodeGen/AArch64 build-vector-extract.ll

[AArch64] add more tests for buildvec to shuffle transform; NFC

These are copied from the sibling x86 file. I'm not sure which
of the current outputs (if any) is considered optimal, but
someone more familiar with AArch may want to take a look.

LLVM/llvm 351753llvm/trunk/lib/CodeGen/SelectionDAG DAGCombiner.cpp, llvm/trunk/test/CodeGen/AArch64 build-vector-extract.ll

[DAGCombiner] fix crash when converting build vector to shuffle

The regression test is reduced from the example shown in D56281.
This does raise a question as noted in the test file: do we want
to handle this pattern? I don't have a motivating example for
that on x86 yet, but it seems like we could have that pattern 
there too, so we could avoid the back-and-forth using a shuffle.

LLVM/llvm 351752cfe/trunk/test/Tooling clang-check-mac-libcxx-fixed-compilation-db.cpp

[test] Pass -ccc-install-dir in mac compilation db test

Pass -ccc-install-dir explicitly as the compilation database code does
not pass argv[0] to getMainExecutable(), while some systems require it
to return the correct path.  Since the relevant code is apparently only
applicable to Darwin, just pass correct -ccc-install-dir to make
the tests pass on *BSD systems.

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

LLVM/llvm 351751clang-tools-extra/trunk/clang-tidy/readability ElseAfterReturnCheck.cpp, clang-tools-extra/trunk/test/clang-tidy readability-else-after-return.cpp

[clang-tidy] Work around http://llvm.org/PR40392

The readability-else-after-return check should be smarter about cases where the
variable defined in the condition is used in the `else` branch. This patch makes
it just ignore such cases, but alternative solutions may be better (added a
FIXME).

LLVM/llvm 351750cfe/trunk/lib/Sema SemaLambda.cpp, cfe/trunk/test/AST ast-dump-expr.cpp

Mark the lambda function pointer conversion operator as noexcept.

This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov.

LLVM/llvm 351749cfe/trunk/www cxx_dr_status.html

Regenerating the C++ DR status page from the latest Core issues list.
DeltaFile
+14,172-14,010cfe/trunk/www/cxx_dr_status.html
+14,172-14,0101 files

LLVM/llvm 351748openmp/trunk/runtime/src/include/50 omp_lib.h.var

NFC: fixed formatting to be consistent across the file

LLVM/llvm 351747cfe/trunk/include/clang/Sema ParsedAttr.h, cfe/trunk/lib/Sema SemaType.cpp SemaOverload.cpp

[OpenCL] Allow address spaces as method qualifiers.

Methods can now be qualified with address spaces to prevent
undesirable conversions to generic or to provide custom 
implementation to be used if the object is located in certain
memory segments.

This commit extends parsing and standard C++ overloading to
work for an address space of a method (i.e. implicit 'this'
parameter).

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

LLVM/llvm 351746cfe/trunk/lib/StaticAnalyzer/Checkers IteratorChecker.cpp

[Analyzer] Remove extra blank line from Iterator Checker (test commit)

LLVM/llvm 351745openmp/trunk/runtime/src/include/50 omp_lib.h.var

Fixed https://reviews.llvm.org/D55078 broken Fortran fixed form.

Long lines split in order to obey Fortran fixed form compilation.

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

LLVM/llvm 351744cfe/trunk/lib/Sema SemaDeclAttr.cpp

[NFC] Fix comparison warning issues by MSVC