------------------------------------------------------------------------
r366868 | rogfer01 | 2019-07-24 07:33:46 +0200 (Wed, 24 Jul 2019) | 6 lines

[RISCV] Implement benchmark::cycleclock::Now

This is a cherrypick of D64237 onto llvm/utils/benchmark and
libcxx/utils/google-benchmark.

Differential Revision: https://reviews.llvm.org/D65142
------------------------------------------------------------------------

llvm-svn: 367813

------------------------------------------------------------------------
r366868 | rogfer01 | 2019-07-24 07:33:46 +0200 (Wed, 24 Jul 2019) | 6 lines

[RISCV] Implement benchmark::cycleclock::Now

This is a cherrypick of D64237 onto llvm/utils/benchmark and
libcxx/utils/google-benchmark.

Differential Revision: https://reviews.llvm.org/D65142
------------------------------------------------------------------------

llvm-svn: 367810

------------------------------------------------------------------------
r367753 | nikic | 2019-08-03 08:47:23 +0200 (Sat, 03 Aug 2019) | 12 lines

[Thumb] Fix invalid symbol redefinition due to duplicated jumptable (PR42760)

Fix for https://bugs.llvm.org/show_bug.cgi?id=42760. A tBR_JTr
instruction is duplicated by tail duplication, which results in
the same jumptable with the same label being emitted twice.

Fix this by marking tBR_JTr as not duplicable. The corresponding
ARM/Thumb instructions are already marked as not duplicable.
Additionally also mark tTBB_JT and tTBH_JT to be consistent with
Thumb2, even though this shouldn't be strictly necessary.

Differential Revision: https://reviews.llvm.org/D65606
------------------------------------------------------------------------

llvm-svn: 367808

------------------------------------------------------------------------
r367687 | ibiryukov | 2019-08-02 17:23:04 +0200 (Fri, 02 Aug 2019) | 16 lines

[clangd] Fix a crash when presenting values for Hover

Summary:
We should pass the expression type, not a variable type when printing
the resulting value. Variable type may be different from what the
pretty-printing function expects, e.g. have references.

Reviewers: sammccall

Reviewed By: sammccall

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

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65655
------------------------------------------------------------------------

llvm-svn: 367807

llvm-svn: 367806

------------------------------------------------------------------------
r367661 | hans | 2019-08-02 09:51:41 +0200 (Fri, 02 Aug 2019) | 5 lines

Don't try emitting dllexported explicitly defaulted non-trivial ctors twice during explicit template instantiation definition (PR42857)

Trying to emit the definition twice triggers an assert.

Differential revision: https://reviews.llvm.org/D65579
------------------------------------------------------------------------

llvm-svn: 367805

------------------------------------------------------------------------
r367520 | hans | 2019-08-01 10:01:09 +0200 (Thu, 01 Aug 2019) | 15 lines

Delay emitting dllexport explicitly defaulted members until the class is fully parsed (PR40006)

This is similar to r245139, but that only addressed dllexported classes.
It was still possible to run into the same problem with dllexported
members in an otherwise normal class (see bug). This uses the same
strategy to fix: delay defining the method until the whole class has
been parsed.

(The easiest way to see the ordering problem is in
Parser::ParseCXXMemberSpecification(): it calls
ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(),
which was trying to define the dllexport method. Now we delay it to
ActOnFinishCXXNonNestedClass() which is called after both of those.)

Differential revision: https://reviews.llvm.org/D65511
------------------------------------------------------------------------

llvm-svn: 367804

------------------------------------------------------------------------
r367530 | ibiryukov | 2019-08-01 11:10:37 +0200 (Thu, 01 Aug 2019) | 17 lines

[Preprocessor] Always discard body of #define if we failed to parse it

Summary:
Preivously we would only discard it if we failed to parse parameter lists.
If we do not consume the body, parser sees tokens inside directive. In
turn, this leads to spurious diagnostics and a crash in TokenBuffer, see
the added tests.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65517
------------------------------------------------------------------------

llvm-svn: 367681

llvm-svn: 367611

llvm-svn: 367610

llvm-svn: 367609

------------------------------------------------------------------------
r366545 | kadircet | 2019-07-19 11:08:22 +0200 (Fri, 19 Jul 2019) | 17 lines

[clangd] Handle windows line endings in QueryDriver

Summary:
The previous patch did not fix the end mark. D64789
fixes second case of https://github.com/clangd/clangd/issues/93

Patch by @lh123 !

Reviewers: sammccall, kadircet

Reviewed By: kadircet

Subscribers: MaskRay, ilya-biryukov, jkorous, arphaman, cfe-commits

Tags: #clang-tools-extra, #clang

Differential Revision: https://reviews.llvm.org/D64970
------------------------------------------------------------------------

llvm-svn: 367571

------------------------------------------------------------------------
r367308 | teemperor | 2019-07-30 14:31:24 +0200 (Tue, 30 Jul 2019) | 27 lines

[lldb] Fix crash when tab-completing in multi-line expr

Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:

    (lldb) expr
    1. a[tab]

Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).

Fixes rdar://51754005

I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.

Reviewers: shafik, davide, labath

Reviewed By: labath

Subscribers: abidh, lldb-commits, davide, clayborg, labath

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64995
------------------------------------------------------------------------

llvm-svn: 367534

------------------------------------------------------------------------
r367417 | lebedevri | 2019-07-31 14:06:38 +0200 (Wed, 31 Jul 2019) | 38 lines

[DivRemPairs] Avoid RAUW pitfalls (PR42823)

Summary:
`DivRemPairs` internally creates two maps:
* {sign, divident, divisor} -> div instruction
* {sign, divident, divisor} -> rem instruction
Then it iterates over rem map, and looks if there is an entry
in div map with the same key. Then depending on some internal logic
it may RAUW rem instruction with something else.

But if that rem instruction is an input to other div/rem,
then it was used as a key in these maps, so the old value (used in key)
is now dandling, because RAUW didn't update those maps.
And we can't even RAUW map keys in general, there's `ValueMap`,
but we don't have a single `Value` as key...

The bug was discovered via D65298, and the test there exists.
Now, i'm not sure how to expose this issue in trunk.
The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`,
but i guess this didn't miscompiled anything thus far?
I really don't think this is benin without that patch.

The fix is actually rather straight-forward - instead of trying to somehow
shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new
`ValueMap` with key being a struct of `Value`s, we can just have an intermediate
data structure - a vector, each entry containing matching `Div, Rem` pair,
and pre-filling it before doing any modifications.
This way we won't need to query map after doing RAUW, so no bug is possible.

Reviewers: spatel, bogner, RKSimon, craig.topper

Reviewed By: spatel

Subscribers: hiraditya, hans, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65451
------------------------------------------------------------------------

llvm-svn: 367531

------------------------------------------------------------------------
r367387 | jdoerfert | 2019-07-31 07:16:38 +0200 (Wed, 31 Jul 2019) | 26 lines

[Fix] Customize warnings for missing built-in types

If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
  - if we could not build the type for the pattern on file (for some
    reason). Here we should make the reason explicit. The actual problem
    is otherwise circumvented as the warning is misleading, see [0] for
    an example.
  - if we could not build the type for the pattern because we do not
    have a type on record, possible since D55483, we should not emit any
    warning. See [1] for a legitimate problem.

This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.

Also see: PR40692

[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583

Differential Revision: https://reviews.llvm.org/D58091
------------------------------------------------------------------------

llvm-svn: 367528

------------------------------------------------------------------------
r367305 | ro | 2019-07-30 12:38:41 +0200 (Tue, 30 Jul 2019) | 32 lines

[Driver] Define _FILE_OFFSET_BITS=64 on Solaris

make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9:

  Undefined                       first referenced
   symbol                             in file
  _ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
  _ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
  ld: fatal: symbol referencing errors
  clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
  make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1

While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9
predefines _FILE_OFFSET_BITS=64 while clang++ currently does not.

This patch resolves this inconsistency by following the gcc lead, which allows
make check-all to finish successfully.

There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for
all languages.  I'd like to keep it this way because those macros do is to make
declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions
of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally.
However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware.
I'd like to restrict this to C++, just like gcc does.

To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64
(e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483.

Tested on x86_64-pc-solaris2.11.

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

------------------------------------------------------------------------

llvm-svn: 367527

------------------------------------------------------------------------
r367304 | ro | 2019-07-30 12:33:20 +0200 (Tue, 30 Jul 2019) | 10 lines

[CMake] Define _FILE_OFFSET_BITS=64 on Solaris

This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure
that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on
Solaris succeed by always making the host and freshly built clang consistent.

Tested on x86_64-pc-solaris2.11.

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

------------------------------------------------------------------------

llvm-svn: 367526

------------------------------------------------------------------------
r367323 | dmajor | 2019-07-30 17:32:49 +0200 (Tue, 30 Jul 2019) | 9 lines

[COFF][ARM64] Reorder handling of aarch64 MSVC builtins

In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins.

Fixes https://llvm.org/pr42775

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


------------------------------------------------------------------------

llvm-svn: 367525

------------------------------------------------------------------------
r367442 | arichardson | 2019-07-31 18:31:55 +0200 (Wed, 31 Jul 2019) | 30 lines

[Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSD

Summary:
MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this
change accesses to the key variable call __tls_get_addr, which is
intercepted. The interceptor then calls GetCurrentThread which calls
MsanTSDGet which again calls __tls_get_addr, etc...
Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN
for me.

I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596)
but that did not work yet. In the ASAN case, we get infinite recursion
again during initialization, this time because calling pthread_key_create() early on
results in infinite recursion. pthread_key_create() calls sysctlbyname()
which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns
true, so the interceptor calls internal_sysctlbyname() which then ends up
calling the interceptor again. I fixed this issue by using dlsym() to get
the libc version of sysctlbyname() instead.

This fixes https://llvm.org/PR40761

Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay

Reviewed By: MaskRay

Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D65221
------------------------------------------------------------------------

llvm-svn: 367524

------------------------------------------------------------------------
r367414 | tkrasnukha | 2019-07-31 14:00:30 +0200 (Wed, 31 Jul 2019) | 7 lines

[ProcessWindows] Choose a register context file by preprocessor

Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows.

Fixes llvm.org/pr42724

Differential Revision: https://reviews.llvm.org/D65409
------------------------------------------------------------------------

llvm-svn: 367523

------------------------------------------------------------------------
r367124 | c-rhodes | 2019-07-26 17:57:50 +0200 (Fri, 26 Jul 2019) | 14 lines

[AArch64][SVE2] Rename bitperm feature to sve2-bitperm

Summary:
The bitperm feature flag is now prefixed with SVE2, as it is for all other SVE2
extensions

Patch by Maciej Gabka.

Reviewers: sdesmalen, rovka, chill, SjoerdMeijer, rengolin

Reviewed By: SjoerdMeijer, rengolin

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

------------------------------------------------------------------------

------------------------------------------------------------------------
r367292 | c-rhodes | 2019-07-30 09:47:48 +0200 (Tue, 30 Jul 2019) | 10 lines

[AArch64][AsmParser] Remove SVE and SVE2 from ARMTargetParser

Summary:
Patch removes SVE and SVE2 features from ARMTargetParser as these
features are not supported on ARM.

Reviewed By: rengolin

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

------------------------------------------------------------------------

------------------------------------------------------------------------
r367394 | c-rhodes | 2019-07-31 10:45:57 +0200 (Wed, 31 Jul 2019) | 25 lines

[AArch64][SVE2] Use destination register as source register

Summary:
This patch fixes a bug in the following instructions that should have been
implemented as destructive. A destructive instruction is an instruction where
one of the source registers also acts as the destination register. Therefore,
the contents of the source register, when the instruction begins execution, are
replaced by the result of the instruction when the instruction completes
execution [1]:

  * SRI/SLI
  * EORBT/EORTB
  * TBX
  * Narrowing top instructions
  * FP convert precision instructions

These changes are non-functional from the assembler/diassembler point-of-view
but are necessary for correct codegen.

[1] https://static.docs.arm.com/ddi0584/ae/DDI0584A_e_SVE_supp_armv8A.pdf

Reviewed By: sdesmalen

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

------------------------------------------------------------------------

------------------------------------------------------------------------
r367396 | c-rhodes | 2019-07-31 10:58:16 +0200 (Wed, 31 Jul 2019) | 15 lines

[AArch64][SVE2] Minor refactoring and cleanup

Summary:
* Clarify comment with SVE2 for predicated shifts and move next to other
  shift instructions.
* Clarify comments for various instructions.
* Move FCVTX instruction next to other fp conversions.
* Move FLOGB to next to other fp instructions and fix description.
* Remove "cons" from non-constructive multiclass for bitwise shift-right
  and accumulate instructions.

Reviewed By: sdesmalen

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

------------------------------------------------------------------------

------------------------------------------------------------------------
r367398 | c-rhodes | 2019-07-31 11:10:36 +0200 (Wed, 31 Jul 2019) | 14 lines

[AArch64][SVE2] Load/store instruction fixes

Summary:
* Loads and stores in SVE2 are gather/scatter not contiguous, fixed by
  renaming multiclasses to reflect this and also updated comments.
* Remove aliases from load/store multiclasses that reflect the behaviour
  of the original form.
* Fix bug in scatter store implementation, vector list should be used as
  input, not output.

Reviewed By: sdesmalen

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

------------------------------------------------------------------------

llvm-svn: 367434

------------------------------------------------------------------------
r366878 | s.desmalen | 2019-07-24 10:42:34 +0200 (Wed, 24 Jul 2019) | 12 lines

[SVE][Inline-Asm] Add support to specify SVE registers in the clobber list

Adds the SVE vector and predicate registers to the list of known registers.

Patch by Kerry McLaughlin.

Reviewers: erichkeane, sdesmalen, rengolin

Reviewed By: sdesmalen

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

------------------------------------------------------------------------

------------------------------------------------------------------------
r367301 | s.desmalen | 2019-07-30 12:14:39 +0200 (Tue, 30 Jul 2019) | 15 lines

[AArch64] Disable __ARM_FEATURE_SVE without ACLE.

The Arm C Language Extensions for SVE document specifies that 
__ARM_FEATURE_SVE should be set when the compiler supports SVE and
implements all the extensions described in the document.

This is currently not yet the case, so the feature should be disabled
until the compiler can provide all the extensions as described.

Reviewers: c-rhodes, rengolin, rovka, ktkachov

Reviewed By: rengolin

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

------------------------------------------------------------------------

llvm-svn: 367432

(Minus the linuxkernel part, which is not present on the branch.)

------------------------------------------------------------------------
r367340 | nico | 2019-07-30 20:16:55 +0200 (Tue, 30 Jul 2019) | 6 lines

gn build: Fix check-clang-tools after r362702.

r362702 added a test that requires clang-tidy to be linked
into libclang, so add that to the gn build.

Differential Revision: https://reviews.llvm.org/D65462
------------------------------------------------------------------------

------------------------------------------------------------------------
r367341 | nico | 2019-07-30 20:19:13 +0200 (Tue, 30 Jul 2019) | 1 line

gn build: Update comment I failed to update in r367340 / D65462
------------------------------------------------------------------------

llvm-svn: 367390

------------------------------------------------------------------------
r366487 | pcc | 2019-07-18 22:14:16 +0200 (Thu, 18 Jul 2019) | 1 line

gn build: Merge r366458.
------------------------------------------------------------------------

llvm-svn: 367317

------------------------------------------------------------------------
r367314 | hans | 2019-07-30 16:17:58 +0200 (Tue, 30 Jul 2019) | 16 lines

gn build: Use rebase_path on filename args to libcxx/utils/gen_link_script.py

  $ ninja -j800
  [1/5] ACTION //libcxx/src:cxx_linker_script(//llvm/utils/gn/build/toolchain:stage2_unix)
  FAILED: lib/libc++.so
  python ../libcxx/utils/gen_link_script.py --input //build.gn/lib/libc++.so.0 --output //build.gn/lib/libc++.so c++abi unwind
  GENERATING SCRIPT: 'INPUT(libc++.so.0 -lc++abi -lunwind)' as file //build.gn/lib/libc++.so
  Traceback (most recent call last):
    File "../libcxx/utils/gen_link_script.py", line 57, in <module>
      sys.exit(main())
    File "../libcxx/utils/gen_link_script.py", line 50, in main
      with open(args.output, 'w') as f:
  IOError: [Errno 2] No such file or directory: '//build.gn/lib/libc++.so'
  ninja: build stopped: subcommand failed.

Differential revision: https://reviews.llvm.org/D65449
------------------------------------------------------------------------

llvm-svn: 367315

------------------------------------------------------------------------
r367008 | stulova | 2019-07-25 13:04:29 +0200 (Thu, 25 Jul 2019) | 12 lines

[OpenCL] Rename lang mode flag for C++ mode

Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++
or -std=clc++/-std=CLC++.

This aligns with OpenCL C conversion and removes ambiguity
with OpenCL C++. 

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



------------------------------------------------------------------------

llvm-svn: 367300

------------------------------------------------------------------------
r367215 | hans | 2019-07-29 11:49:04 +0200 (Mon, 29 Jul 2019) | 66 lines

Mark test/MC/RISCV/rv{32,64}i-aliases-invalid.s unsupported also on Windows

Because they fail there too.

FAIL: LLVM :: MC/RISCV/rv32i-aliases-invalid.s (24397 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv32i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2';   not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
: 'RUN: at line 3';   not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s -triple=riscv32 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s" "-triple=riscv32" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv32i-aliases-invalid.s:10:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
                    ^
<stdin>:5:1: note: scanning from here
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:1: note: with "@LINE" equal to "10"
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
^
<stdin>:5:38: note: possible intended match here
li x0, -2147483649 # CHECK: :[[@LINE]]:8: error: immediate must be an integer in the range [-2147483648, 4294967295]
                                     ^

error: command failed with exit status: 1

--

--
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70
FAIL: LLVM :: MC/RISCV/rv64i-aliases-invalid.s (24416 of 32659)
******************** TEST 'LLVM :: MC/RISCV/rv64i-aliases-invalid.s' FAILED ********************
Script:
--
: 'RUN: at line 2';   not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 -riscv-no-aliases 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
: 'RUN: at line 3';   not c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s -triple=riscv64 2>&1 | c:\src\llvm.monorepo\build.release2\bin\filecheck.exe C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 2"
$ "not" "c:\src\llvm.monorepo\build.release2\bin\llvm-mc.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s" "-triple=riscv64" "-riscv-no-aliases"
$ "c:\src\llvm.monorepo\build.release2\bin\filecheck.exe" "C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s"
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:6:21: error: CHECK: expected string not found in input
li t4, foo # CHECK: :[[@LINE]]:8: error: operand must be a constant 64-bit integer
                    ^
<stdin>:2:1: note: scanning from here
li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand
^
<stdin>:2:1: note: with "@LINE" equal to "6"
li t5, 0x10000000000000000 # CHECK: :[[@LINE]]:8: error: unknown operand
^
<stdin>:13:67: note: possible intended match here
C:\src\llvm.monorepo\llvm\test\MC\RISCV\rv64i-aliases-invalid.s:12:13: error: immediate must be an integer in the range [0, 63]
                                                                  ^

error: command failed with exit status: 1
------------------------------------------------------------------------

llvm-svn: 367217

llvm-svn: 367212

------------------------------------------------------------------------
r367062 | yhs | 2019-07-25 23:47:27 +0200 (Thu, 25 Jul 2019) | 30 lines

[BPF] fix typedef issue for offset relocation

Currently, the CO-RE offset relocation does not work
if any struct/union member or array element is a typedef.
For example,
  typedef const int arr_t[7];
  struct input {
      arr_t a;
  };
  func(...) {
       struct input *in = ...;
       ... __builtin_preserve_access_index(&in->a[1]) ...
  }
The BPF backend calculated default offset is 0 while
4 is the correct answer. Similar issues exist for struct/union
typedef's.

When getting struct/union member or array element type,
we should trace down to the type by skipping typedef
and qualifiers const/volatile as this is what clang did
to generate getelementptr instructions.
(const/volatile member type qualifiers are already
ignored by clang.)

This patch fixed this issue, for each access index,
skipping typedef and const/volatile/restrict BTF types.

Signed-off-by: Yonghong Song <yhs@fb.com>

Differential Revision: https://reviews.llvm.org/D65259
------------------------------------------------------------------------

llvm-svn: 367211

------------------------------------------------------------------------
r367030 | yhs | 2019-07-25 18:01:26 +0200 (Thu, 25 Jul 2019) | 38 lines

[BPF] fix CO-RE incorrect index access string

Currently, we expect the CO-RE offset relocation records
a string encoding the original getelementptr access index,
so kernel bpf loader can decode it correctly.

For example,
  struct s { int a; int b; };
  struct t { int c; int d; };
  #define _(x) (__builtin_preserve_access_index(x))
  int get_value(const void *addr1, const void *addr2);
  int test(struct s *arg1, struct t *arg2) {
    return get_value(_(&arg1->b), _(&arg2->d));
  }

We expect two offset relocations:
  reloc 1: type s, access index 0, 1
  reloc 2: type t, access index 0, 1

Two globals are created to retain access indexes for the
above two relocations with global variable names.
The first global has a name "0:1:". Unfortunately,
the second global has the name "0:1:.1" as the llvm
internals automatically add suffix ".1" to a global
with the same name. Later on, the BPF peels the last
character and record "0:1" and "0:1:." in the
relocation table.

This is not desirable. BPF backend could use the global
variable suffix knowledge to generate correct access str.
This patch rather took an approach not relying on
that knowledge. It generates "s:0:1:" and "t:0:1:" to
avoid global variable suffixes and later on generate
correct index access string "0:1" for both records.

Signed-off-by: Yonghong Song <yhs@fb.com>

Differential Revision: https://reviews.llvm.org/D65258
------------------------------------------------------------------------

llvm-svn: 367210

------------------------------------------------------------------------
r367055 | compnerd | 2019-07-25 22:59:48 +0200 (Thu, 25 Jul 2019) | 6 lines

Revert "Revert "CodeGen: ensure placeholder instruction for cleanup is created""

This reverts commit fd1274fa78cb0fd32cc1fa2e6f5bb8e62d29df19.

Add an explicit triple for the test which is pattern matching overly
aggressively.
------------------------------------------------------------------------

llvm-svn: 367209

By Nick Desaulniers!

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

llvm-svn: 367158

------------------------------------------------------------------------
r367134 | nathan-huckleberry | 2019-07-26 19:29:35 +0200 (Fri, 26 Jul 2019) | 16 lines

[Sema] Fix -Wuninitialized for struct assignment from GNU C statement expression

Summary:
Do not automatically report self references of structs in statement expression
as warnings. Instead wait for uninitialized cfg analysis.
https://bugs.llvm.org/show_bug.cgi?id=42604

Reviewers: aaron.ballman, rsmith, nickdesaulniers

Reviewed By: aaron.ballman, nickdesaulniers

Subscribers: nathanchance, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64678
------------------------------------------------------------------------

llvm-svn: 367150

------------------------------------------------------------------------
r367112 | sammccall | 2019-07-26 16:07:11 +0200 (Fri, 26 Jul 2019) | 11 lines

[clangd] Fix background index not triggering on windows due to case mismatch.

Summary:
This isn't a general fix to all paths where we assume case-sensitivity, it's
a minimally-invasive fix targeting the llvm 9 branch.

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65320
------------------------------------------------------------------------

llvm-svn: 367135

------------------------------------------------------------------------
r367039 | erichkeane | 2019-07-25 19:14:45 +0200 (Thu, 25 Jul 2019) | 6 lines

Remove CallingConvMethodType

This seems to be an old vestage of a previous implementation of getting
the default calling convention, and everything is now using
CXXABI/ASTContext's getDefaultCallingConvention.  Remove it, since it
isn't doing anything.
------------------------------------------------------------------------

------------------------------------------------------------------------
r367103 | erichkeane | 2019-07-26 14:36:12 +0200 (Fri, 26 Jul 2019) | 6 lines

Make the CXXABIs respect the target's default calling convention.

SPIR targets need to have all functions be SPIR calling convention,
however the CXXABIs were just returning CC_C in all non-'this-CC' cases.

https://reviews.llvm.org/D65294
------------------------------------------------------------------------

llvm-svn: 367129

------------------------------------------------------------------------
r366985 | labath | 2019-07-25 08:38:33 +0200 (Thu, 25 Jul 2019) | 16 lines

LLGS: fix tracking execve on linux

Summary:
Due to a logic error, lldb-server ended up asserting/crashing every time
the debugged process attempted an execve(). This fixes the error, and
extends TestExec to work on other platforms too. The "extension"
consists of avoiding non-standard posix_spawn extensions and using the
classic execve() call, which should be available on any platform that
actually supports re-execing. I change the test decorator from
@skipUnlessDarwin to @skipIfWindows.

Reviewers: clayborg, jasonmolenda

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D65207
------------------------------------------------------------------------

llvm-svn: 367128

------------------------------------------------------------------------
r366811 | sammccall | 2019-07-23 16:30:28 +0200 (Tue, 23 Jul 2019) | 9 lines

[clangd] Log version, cwd, args, and transport on startup. NFC

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65146
------------------------------------------------------------------------

------------------------------------------------------------------------
r366880 | sammccall | 2019-07-24 11:33:27 +0200 (Wed, 24 Jul 2019) | 9 lines

[clangd] Reformat use of cl::opt: use unqualified name and don't bin-pack attributes. NFC

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65154
------------------------------------------------------------------------

------------------------------------------------------------------------
r366900 | sammccall | 2019-07-24 14:41:52 +0200 (Wed, 24 Jul 2019) | 16 lines

[clangd] Add categories to help options, and only show clangd options.

Summary:
Restricting the categories prevents extra unwanted options from creeping into
help (D60663), and removes a bunch of noise from --help-hidden.

While here, remove `static` from the opts in favor of an anon namespace, to
reduce the noise level.

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65200
------------------------------------------------------------------------

------------------------------------------------------------------------
r366991 | sammccall | 2019-07-25 09:54:48 +0200 (Thu, 25 Jul 2019) | 13 lines

[clangd] Also accept flags from CLANGD_FLAGS variable.

This simplifies various workflows, particularly in debugging/development.
e.g. editors will tend to propagate flags, so you can run
`env CLANGD_FLAGS=-input-mirror-file=/tmp/mirror vim foo.cc` rather than
change the configuration in a persistent way.
(This also gives us a generic lever when we don't know how to customize
the flags in some particular LSP client).

While here, add a test for this and other startup logging, and fix a
couple of direct writes to errs() that should have been logs.

Differential Revision: https://reviews.llvm.org/D65153
------------------------------------------------------------------------

------------------------------------------------------------------------
r366992 | sammccall | 2019-07-25 10:00:54 +0200 (Thu, 25 Jul 2019) | 9 lines

[clangd] Provide help text to users who run `clangd` in a terminal.

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65201
------------------------------------------------------------------------

llvm-svn: 367025

$ bin/clang-tblgen -gen-diag-docs -I../cfe.src/include \
      -I../cfe.src/include/clang/Basic/ \
      ../cfe.src/include/clang/Basic/Diagnostic.td -o \
      ../cfe.src/docs/DiagnosticsReference.rst && \
bin/clang-tblgen -gen-attr-docs -I../cfe.src/include \
        ../cfe.src/include/clang/Basic/Attr.td -o \
        ../cfe.src/docs/AttributeReference.rst && \
bin/clang-tblgen -gen-opt-docs -I../cfe.src/include \
        -I../cfe.src/include/clang/Driver -I../llvm.src/include \
        ../cfe.src/include/clang/Driver/ClangOptionDocs.td -o \
        ../cfe.src/docs/ClangCommandLineReference.rst

llvm-svn: 366971

------------------------------------------------------------------------
r366925 | xbolva00 | 2019-07-24 19:01:20 +0200 (Wed, 24 Jul 2019) | 13 lines

[InstCombine] Adjusted pow-exp tests for Windows [NFC]

Summary: https://bugs.llvm.org/show_bug.cgi?id=42740

Reviewers: efriedma, hans

Reviewed By: hans

Subscribers: spatel, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65220
------------------------------------------------------------------------

llvm-svn: 366940

------------------------------------------------------------------------
r366780 | mstorsjo | 2019-07-23 08:38:04 +0200 (Tue, 23 Jul 2019) | 21 lines

[COFF] Unbreak sorting of mingw comdat .tls sections after SVN r363457

Code built for mingw with -fdata-sections will store each TLS variable
in a comdat section, named .tls$$<varname>. Normal TLS variables are
stored in sections named .tls$ with a trailing dollar, which are
sorted after a starter marker (in a later linked object file) in a
section named ".tls" (with no dollar suffix), before an ending marker
in a section named ".tls$ZZZ".

The mingw comdat section suffix stripping introduced in SVN r363457
broke sorting of such tls sections, ending up sorting the stripped
.tls$$<varname> sections (stripped to ".tls") before the start marker
in the section named ".tls".

We could add exceptions to the section name suffix stripping for
.tls (and .CRT, where suffixes always should be honored), but the
more conservative option is probably the reverse; to only apply the
stripping for the normal sections where sorting shouldn't have any
effect.

Differential Revision: https://reviews.llvm.org/D65018
------------------------------------------------------------------------

------------------------------------------------------------------------
r366784 | mstorsjo | 2019-07-23 09:28:23 +0200 (Tue, 23 Jul 2019) | 4 lines

[test] Fix the test from the previous commit when run on windows. NFC.

Apparently the escaped dollar sign didn't work the same way in "echo -e"
on windows buildbots.
------------------------------------------------------------------------

llvm-svn: 366816