> [lit] Fix 42812: lit test suite can no longer be run stand-alone
>
> Summary:
> This change updates the lit.cfg file to use llvm_config when it is available, but when it is not, it directly modifies the config object. This makes it possible to run the lit tests standalone without having built llvm (as long as the correct binaries are present in the path such as FileCheck and not).
>
> Because the lit tests don't take a hard dependency on llvm_config, some features such as system-windows have to have definitions in lit's cfg file as well. This is a potential issue as the os features sometimes change names (for example, we went from windows to system-windows, etc.). This can cause drift between lit's tests and the rest of the llvm tests.
>
> Reviewers: probinson, mgorny
>
> Reviewed By: mgorny
>
> Subscribers: delcypher, llvm-commits, asmith
>
> Tags: #llvm
>
> Differential Revision: https://reviews.llvm.org/D65674

llvm-svn: 367993

llvm-svn: 367992

------------------------------------------------------------------------
r366660 | rksimon | 2019-07-21 21:04:44 +0200 (Sun, 21 Jul 2019) | 3 lines

[X86] SimplifyDemandedVectorEltsForTargetNode - Move SUBV_BROADCAST narrowing handling. NFCI.

Move the narrowing of SUBV_BROADCAST to where we handle all the other opcodes.
------------------------------------------------------------------------

------------------------------------------------------------------------
r367306 | rksimon | 2019-07-30 13:35:13 +0200 (Tue, 30 Jul 2019) | 5 lines

[X86][AVX] SimplifyDemandedVectorElts - handle extraction from X86ISD::SUBV_BROADCAST source (PR42819)

PR42819 showed an issue that we couldn't handle the case where we demanded a 'sub-sub-vector' of the SUBV_BROADCAST 'sub-vector' source.

This patch recognizes these cases and extracts the sub-sub-vector instead of trying to broadcast to a type smaller than the 'sub-vector' source. 
------------------------------------------------------------------------

llvm-svn: 367991

------------------------------------------------------------------------
r367675 | stulova | 2019-08-02 13:19:35 +0200 (Fri, 02 Aug 2019) | 10 lines

[OpenCL] Allow OpenCL C style vector initialization in C++

Allow creating vector literals from other vectors.

 float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
 float4 v = (float4)(a.s23, a.s01);

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


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

------------------------------------------------------------------------
r367823 | stulova | 2019-08-05 11:50:28 +0200 (Mon, 05 Aug 2019) | 6 lines

[OpenCL] Fix vector literal test broken in rL367675.

Avoid checking alignment unnecessary that is not portable
among targets.


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

llvm-svn: 367987

------------------------------------------------------------------------
r367836 | mstorsjo | 2019-08-05 13:57:00 +0200 (Mon, 05 Aug 2019) | 17 lines

[COFF] Omit automatically imported symbols from the symbol table

These symbols actually point to the symbol's IAT entry, which
obviously is different from the symbol itself (which is imported
from a different module and doesn't exist in the current one).

Omitting this symbol helps gdb inspect automatically imported
symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574
for discussion on the matter.

Surprisingly, those extra symbols don't seem to be an issue for
gdb when the sources have been built with clang, only with gcc.
The actual logic in gdb that this depends on still is unknown, but
omitting these symbols from the symbol table is the right thing to
do in any case.

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

llvm-svn: 367986

------------------------------------------------------------------------
r367846 | hans | 2019-08-05 15:04:07 +0200 (Mon, 05 Aug 2019) | 1 line

Write the RequiredLibraries for 'all' in LibraryDependencies.inc in a deterministic order (PR42739)
------------------------------------------------------------------------

------------------------------------------------------------------------
r367847 | hans | 2019-08-05 15:04:12 +0200 (Mon, 05 Aug 2019) | 8 lines

test-release.sh: Perform the sed substitution on both files (PR42739)

The comparison would otherwise fail if Phase2 occurrs naturally in the
object file. It would get replaced with Phase3 in the one .o, but not
in the other.

We were already running both files through sed to have them processed in
this same way; this is a logical extension of that.
------------------------------------------------------------------------

llvm-svn: 367848

------------------------------------------------------------------------
r367662 | psmith | 2019-08-02 10:05:14 +0200 (Fri, 02 Aug 2019) | 17 lines

[AliasAnalysis] Initialize a member variable that may be used by unit test.

The unit tests in BasicAliasAnalysisTest use the alias analysis API
directly and do not call setAAResults to initalize AAR. This gives a
valgrind error "Conditional Jump depends on unitialized variable".

On most buildbots the variable is nullptr, but in some cases it can be
non nullptr leading to seemingly random failures.

These tests were disabled in r366986. With the initialization they can be
enabled again.

Fixes PR42719

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


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

llvm-svn: 367818

------------------------------------------------------------------------
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