------------------------------------------------------------------------
r371969 | karka | 2019-09-16 11:52:23 +0200 (Mon, 16 Sep 2019) | 13 lines

Change signature of __builtin_rotateright64 back to unsigned

The signature of __builtin_rotateright64 was by misstake changed from
unsigned to signed in r360863, this patch will change it back to
unsigned as intended.

This fixes pr43309

Reviewers: efriedma, hans

Reviewed By: hans

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

llvm-svn: 372100

llvm-svn: 371964

------------------------------------------------------------------------
r371766 | nickdesaulniers | 2019-09-12 21:53:35 +0200 (Thu, 12 Sep 2019) | 29 lines

[Clang][CodeGen] support alias attribute w/ gnu_inline

Summary:
r369705 did not consider the addition of gnu_inline on function
declarations of alias attributed functions. This resulted in a reported
regression in the clang-9-rc4 release from the Zig developers building
glibc, which was observable as a failed assertion:

llvm-project/clang/lib/AST/Decl.cpp:3336: bool
clang::FunctionDecl::isInlineDefinitionExternallyVisible() const:
Assertion `(doesThisDeclarationHaveABody() || willHaveBody()) && "Must
be a function definition"' failed.

Alias function declarations do not have bodies, so allow us to proceed
if we have the alias function attribute but no body/definition, and add
a test case.  The emitted symbols and their linkage matches GCC for the
added test case.

Link: https://bugs.llvm.org/show_bug.cgi?id=43268

Reviewers: aaron.ballman, rsmith, erichkeane, andrewrk

Reviewed By: andrewrk

Subscribers: cfe-commits, andrewrk, hans, srhines

Tags: #clang

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

llvm-svn: 371821

------------------------------------------------------------------------
r371434 | efriedma | 2019-09-09 20:29:27 +0200 (Mon, 09 Sep 2019) | 15 lines

[IfConversion] Correctly handle cases where analyzeBranch fails.

If analyzeBranch fails, on some targets, the out parameters point to
some blocks in the function. But we can't use that information, so make
sure to clear it out.  (In some places in IfConversion, we assume that
any block with a TrueBB is analyzable.)

The change to the testcase makes it trigger a bug on builds without this
fix: IfConvertDiamond tries to perform a followup "merge" operation,
which isn't legal, and we somehow end up with a branch to a deleted MBB.
I'm not sure how this doesn't crash the compiler.

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


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

llvm-svn: 371490

------------------------------------------------------------------------
r370592 | rksimon | 2019-08-31 18:21:31 +0200 (Sat, 31 Aug 2019) | 3 lines

[X86] EltsFromConsecutiveLoads - Don't confuse elt count with vector element count (PR43170)

EltsFromConsecutiveLoads was assuming that the number of input elts was the same as the number of elements in the output vector type when creating a zeroing shuffle, causing an assert when subvectors were being combined instead of just scalars.
------------------------------------------------------------------------

llvm-svn: 371382

------------------------------------------------------------------------
r371221 | spatel | 2019-09-06 18:10:18 +0200 (Fri, 06 Sep 2019) | 3 lines

[SimplifyLibCalls] handle pow(x,-0.0) before it can assert (PR43233)

https://bugs.llvm.org/show_bug.cgi?id=43233
------------------------------------------------------------------------

------------------------------------------------------------------------
r371224 | jfb | 2019-09-06 18:26:59 +0200 (Fri, 06 Sep 2019) | 39 lines

[InstCombine] pow(x, +/- 0.0) -> 1.0

Summary:
This isn't an important optimization at all... We're already doing:
  pow(x, 0.0) -> 1.0
My patch merely teaches instcombine that -0.0 does the same.

However, doing this fixes an AMAZING bug! Compile this program:

  extern "C" double pow(double, double);
  double boom(double base) {
    return pow(base, -0.0);
  }

With:
  clang++ ~/Desktop/fast-math.cpp -ffast-math -O2 -S

And clang will crash with a signal. Wow, fast math is so fast it ICEs the
compiler! Arguably, the generated math is infinitely fast.

What's actually happening is that we recurse infinitely in getPow. In debug we
hit its assertion:
  assert(Exp != 0 && "Incorrect exponent 0 not handled");

We avoid this entire mess if we instead recognize that an exponent of positive
and negative zero yield 1.0.

A separate commit, r371221, fixed the same problem. This only contains the added
tests.

<rdar://problem/54598300>

Reviewers: scanon

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

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

llvm-svn: 371381

------------------------------------------------------------------------
r371305 | nikic | 2019-09-07 14:03:48 +0200 (Sat, 07 Sep 2019) | 1 line

[X86] Add test for PR43230; NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r371307 | nikic | 2019-09-07 14:13:44 +0200 (Sat, 07 Sep 2019) | 9 lines

[X86] Fix pshuflw formation from repeated shuffle mask (PR43230)

Fix for https://bugs.llvm.org/show_bug.cgi?id=43230.

When creating PSHUFLW from a repeated shuffle mask, we have to apply
the checks to the repeated mask, not the original one. For the test
case from PR43230 the inspected part of the original mask is all undef.

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

llvm-svn: 371378

------------------------------------------------------------------------
r371111 | efriedma | 2019-09-05 22:02:38 +0200 (Thu, 05 Sep 2019) | 17 lines

[IfConversion] Fix diamond conversion with unanalyzable branches.

The code was incorrectly counting the number of identical instructions,
and therefore tried to predicate an instruction which should not have
been predicated.  This could have various effects: a compiler crash,
an assembler failure, a miscompile, or just generating an extra,
unnecessary instruction.

Instead of depending on TargetInstrInfo::removeBranch, which only
works on analyzable branches, just remove all branch instructions.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and
https://bugs.llvm.org/show_bug.cgi?id=41121 .

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


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

llvm-svn: 371377

------------------------------------------------------------------------
r371262 | nickdesaulniers | 2019-09-06 23:50:11 +0200 (Fri, 06 Sep 2019) | 45 lines

[IR] CallBrInst: scan+update arg list when indirect dest list changes

Summary:
There's an unspoken invariant of callbr that the list of BlockAddress
Constants in the "function args" list match the BasicBlocks in the
"other labels" list. (This invariant is being added to the LangRef in
https://reviews.llvm.org/D67196).

When modifying the any of the indirect destinations of a callbr
instruction (possible jump targets), we need to update the function
arguments if the argument is a BlockAddress whose BasicBlock refers to
the indirect destination BasicBlock being replaced.  Otherwise, many
transforms that modify successors will end up violating that invariant.
A recent change to the arm64 Linux kernel exposed this bug, which
prevents the kernel from booting.

I considered maintaining a mapping from indirect destination BasicBlock
to argument operand BlockAddress, but this ends up being a one to
potentially many (though usually one) mapping.  Also, the list of
arguments to a function (or more typically inline assembly) ends up
being less than 10.  The implementation is significantly simpler to just
rescan the full list of arguments. Because of the one to potentially
many relationship, the full arg list must be scanned (we can't stop at
the first instance).

Thanks to the following folks that reported the issue and helped debug
it:
* Nathan Chancellor
* Will Deacon
* Andrew Murray
* Craig Topper

Link: https://bugs.llvm.org/show_bug.cgi?id=43222
Link: https://github.com/ClangBuiltLinux/linux/issues/649
Link: https://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/678330.html

Reviewers: craig.topper, chandlerc

Reviewed By: craig.topper

Subscribers: void, javed.absar, kristof.beyls, hiraditya, llvm-commits, nathanchance, srhines

Tags: #llvm

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

llvm-svn: 371376

------------------------------------------------------------------------
r369705 | nickdesaulniers | 2019-08-22 22:47:12 +0200 (Thu, 22 Aug 2019) | 23 lines

[Clang][CodeGen] set alias linkage on QualType

Summary:
It seems that CodeGen was always using ExternalLinkage when emitting a
GlobalDecl with __attribute__((alias)). This leads to symbol
redefinitions (ODR) that cause failures at link time for static aliases.
This is readily attempting to link an ARM (32b) allyesconfig Linux
kernel built with Clang.

Reported-by: nathanchance
Suggested-by: ihalip
Link: https://bugs.llvm.org/show_bug.cgi?id=42377
Link: https://github.com/ClangBuiltLinux/linux/issues/631

Reviewers: rsmith, aaron.ballman, erichkeane

Reviewed By: aaron.ballman

Subscribers: javed.absar, kristof.beyls, cfe-commits, srhines, ihalip, nathanchance

Tags: #clang

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

------------------------------------------------------------------------
r369713 | nickdesaulniers | 2019-08-23 01:18:46 +0200 (Fri, 23 Aug 2019) | 17 lines

[Bugfix] fix r369705 unit test

Summary:
Aliases aren't supported on OSX.  Add a GNU target triple.

Reported-by: leonardchan
Reported-by: erik.pilkington

Reviewers: leonardchan, erik.pilkington

Reviewed By: leonardchan, erik.pilkington

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 371372

No --wrap or --emit-relocs options have been added there (only in
the ELF linker).

llvm-svn: 371301

------------------------------------------------------------------------
r371013 | ruiu | 2019-09-05 07:30:24 +0200 (Thu, 05 Sep 2019) | 13 lines

Align output segments correctly

Previously, segments were aligned according to their first section's
alignment requirements. That was not correct, but segments are also
aligned to a page boundary, and a page boundary is usually much larger
than a section alignment requirement, so no one noticed this bug before.

Now, lld has --nmagic option which sets maxPageSize to 1 to effectively
disable page alignment, which reveals the issue.

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

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

llvm-svn: 371197

------------------------------------------------------------------------
r369828 | maskray | 2019-08-24 02:41:15 +0200 (Sat, 24 Aug 2019) | 18 lines

[ELF] Align the first section of a PT_LOAD even if its type is SHT_NOBITS

Reported at https://reviews.llvm.org/D64930#1642223

If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss), we
may not align its sh_offset. p_offset of the PT_LOAD will be set to
sh_offset, and we will get p_offset!=p_vaddr (mod p_align).  If such
executable is mapped by the Linux kernel, it will segfault.

After D64906, this may happen the non-linker script case.

The linker script case has had this issue for a long time.
This was fixed by rL321657 (but the test linkerscript/nobits-offset.s
failed to test a SHT_NOBITS section), but broken by rL345154.

Reviewed By: peter.smith

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

llvm-svn: 371196

------------------------------------------------------------------------
r371088 | spatel | 2019-09-05 18:58:18 +0200 (Thu, 05 Sep 2019) | 1 line

[x86] add test for horizontal math bug (PR43225); NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r371095 | spatel | 2019-09-05 19:28:17 +0200 (Thu, 05 Sep 2019) | 3 lines

[x86] fix horizontal math bug exposed by improved demanded elements analysis (PR43225)

https://bugs.llvm.org/show_bug.cgi?id=43225
------------------------------------------------------------------------

llvm-svn: 371178

------------------------------------------------------------------------
r371027 | hans | 2019-09-05 10:43:00 +0200 (Thu, 05 Sep 2019) | 20 lines

Revert r361885 "[Driver] Fix -working-directory issues"

This made clang unable to open files using relative paths on network shares on
Windows (PR43204). On the bug it was pointed out that createPhysicalFileSystem()
is not terribly mature, and using it is risky. Reverting for now until there's
a clear way forward.

> Currently the `-working-directory` option does not actually impact the working
> directory for all of the clang driver, it only impacts how files are looked up
> to make sure they exist.  This means that that clang passes the wrong paths
> to -fdebug-compilation-dir and -coverage-notes-file.
>
> This patch fixes that by changing all the places in the driver where we convert
> to absolute paths to use the VFS, and then calling setCurrentWorkingDirectory on
> the VFS.  This also changes the default VFS for `Driver` to use a virtualiz...

------------------------------------------------------------------------
r370426 | maskray | 2019-08-30 04:20:49 +0200 (Fri, 30 Aug 2019) | 26 lines

[PPC32] Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO

Unlike ppc64, which has ADDISgotTprelHA+LDgotTprelL pairs,
ppc32 just uses LDgotTprelL32, so it does not make lots of sense to use
_LO without a paired _HA.

Emit R_PPC_GOT_TPREL16 instead R_PPC_GOT_TPREL16_LO to match GCC, and
get better linker relocation check. Note, R_PPC_GOT_TPREL16_{HA,LO}
don't have good linker support:

(a) lld does not support R_PPC_GOT_TPREL16_{HA,LO}.
(b) Top of tree ld.bfd does not support R_PPC_GOT_REL16_HA Initial-Exec -> Local-Exec relaxation:

  // a.o
  addis 3, 3, tsd_tls@got@tprel@ha
  lwz 3, tsd_tls@got@tprel@l(3)
  add 3, 3, tsd_tls@tls
  // b.o
  .section .tdata,"awT"; .globl tsd_tls; tsd_tls:

  // ld/ld-new a.o b.o
  internal error, aborting at ../../bfd/elf32-ppc.c:7952 in ppc_elf_relocate_section

Reviewed By: adalava

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

llvm-svn: 371059

------------------------------------------------------------------------
r369760 | szelethus | 2019-08-23 16:21:13 +0200 (Fri, 23 Aug 2019) | 13 lines

[analyzer] Avoid unnecessary enum range check on LValueToRValue casts

Summary: EnumCastOutOfRangeChecker should not perform enum range checks on LValueToRValue casts, since this type of cast does not actually change the underlying type.   Performing the unnecessary check actually triggered an assertion failure deeper in EnumCastOutOfRange for certain input (which is captured in the accompanying test code).

Reviewers: #clang, Szelethus, gamesh411, NoQ

Reviewed By: Szelethus, gamesh411, NoQ

Subscribers: NoQ, gamesh411, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, bjope, cfe-commits

Tags: #clang

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

llvm-svn: 371058

------------------------------------------------------------------------
r371048 | jonpa | 2019-09-05 12:20:05 +0200 (Thu, 05 Sep 2019) | 7 lines

[SystemZ]  Recognize INLINEASM_BR in backend

Handle the remaining cases also by handling asm goto in
SystemZInstrInfo::getBranchInfo().

Review: Ulrich Weigand
https://reviews.llvm.org/D67151
------------------------------------------------------------------------

llvm-svn: 371057

------------------------------------------------------------------------
r370430 | djg | 2019-08-30 06:33:22 +0200 (Fri, 30 Aug 2019) | 12 lines

[CodeGen] Fix lowering for returning the result of an extractvalue

When the number of return values exceeds the number of registers available,
SelectionDAGBuilder::visitRet transforms a function's return to use a
pointer to a buffer to hold return values. When the returned value is an
operator such as extractvalue, the value may have a non-zero result number.
Add that number to the indexing when obtaining the values to store.

This fixes https://bugs.llvm.org/show_bug.cgi?id=43132.

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

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

llvm-svn: 371053

------------------------------------------------------------------------
r370720 | bjope | 2019-09-03 11:33:40 +0200 (Tue, 03 Sep 2019) | 13 lines

[LV] Precommit test case showing miscompile from PR43166. NFC

Summary:  Precommit test case showing miscompile from PR43166.

Reviewers: fhahn, Ayal

Reviewed By: fhahn

Subscribers: rkruppe, llvm-commits

Tags: #llvm

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

------------------------------------------------------------------------
r370721 | bjope | 2019-09-03 11:33:55 +0200 (Tue, 03 Sep 2019) | 20 lines

[LV] Fix miscompiles by adding non-header PHI nodes to AllowedExit

Summary:
Fold-tail currently supports reduction last-vector-value live-out's,
but has yet to support last-scalar-value live-outs, including
non-header phi's. As it relies on AllowedExit in order to detect
them and bail out we need to add the non-header PHI nodes to
AllowedExit, otherwise we end up with miscompiles.

Solves https://bugs.llvm.org/show_bug.cgi?id=43166

Reviewers: fhahn, Ayal

Reviewed By: fhahn, Ayal

Subscribers: anna, hiraditya, rkruppe, llvm-commits

Tags: #llvm

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

llvm-svn: 371044

------------------------------------------------------------------------
r370753 | jonpa | 2019-09-03 15:31:22 +0200 (Tue, 03 Sep 2019) | 6 lines

[SystemZ]  Recognize INLINEASM_BR in backend.

SystemZInstrInfo::analyzeBranch() needs to check for INLINEASM_BR
instructions, or it will crash.

Review: Ulrich Weigand
------------------------------------------------------------------------

llvm-svn: 371043

------------------------------------------------------------------------
r369310 | hubert.reinterpretcast | 2019-08-20 01:12:48 +0200 (Tue, 20 Aug 2019) | 24 lines

[cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFC

Summary:
rL367756 (f5c40cb9) increases the dependency of LLVMOrcJIT on LLVMPasses.
In particular, symbols defined in LLVMPasses that are referenced by the
destructor of `PassBuilder` are now referenced by LLVMOrcJIT through
`Speculation.cpp.o`.

We believe that referencing symbols defined in LLVMPasses in the
destructor of `PassBuilder` is valid, and that adding to the set of such
symbols is legitimate. To support such cases, this patch adds LLVMPasses
to the set of libraries being linked when linking in LLVMOrcJIT causes
such symbols from LLVMPasses to be referenced.

Reviewers: Whitney, anhtuyen, pree-jackie

Reviewed By: pree-jackie

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

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

llvm-svn: 371042

------------------------------------------------------------------------
r370850 | hans | 2019-09-04 10:19:30 +0200 (Wed, 04 Sep 2019) | 20 lines

Re-commit r363191 "[MS] Pretend constexpr variable template specializations are inline"

While the next Visual Studio update (16.3) will fix this issue, that hasn't
shipped yet. Until then Clang wouldn't work with MSVC's headers which seems
unfortunate. Let's keep this in until VS 16.3 ships. (See also PR42843.)

> Fixes link errors with clang and the latest Visual C++ 14.21.27702
> headers, which was reported as PR42027.
>
> I chose to intentionally make these things linkonce_odr, i.e.
> discardable, so that we don't emit definitions of these things in every
> translation unit that includes STL headers.
>
> Note that this is *not* what MSVC does: MSVC has not yet implemented C++
> DR2387, so they emit fully specialized constexpr variable templates with
> static / internal linkage.
>
> Reviewers: rsmith
>
> Differential Revision: https://reviews.llvm.org/D63175
------------------------------------------------------------------------

llvm-svn: 371040

llvm-svn: 371037

llvm-svn: 371034

This patch updates the libc++ release notes.
I have picked out several features/fixes/updates
that I think are worth mentioning.

llvm-svn: 370514

llvm-svn: 370477

$ 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: 370450

------------------------------------------------------------------------
r370355 | joerg | 2019-08-29 15:22:30 +0200 (Thu, 29 Aug 2019) | 5 lines

Allow replaceAndRecursivelySimplify to list unsimplified visitees.

This is part of D65280 and split it to avoid ABI changes on the 9.0
release branch.

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

llvm-svn: 370447

------------------------------------------------------------------------
r370404 | rksimon | 2019-08-29 22:22:08 +0200 (Thu, 29 Aug 2019) | 3 lines

[X86][SSE] combinePMULDQ - pmuldq(x, 0) -> zero vector (PR43159)

ISD::isBuildVectorAllZeros permits undef elements to be present, which means we can't return it as a zero vector. PMULDQ/PMULUDQ is an extending multiply so a multiply by zero of the lower 32-bits should result in a zero 64-bit element.
------------------------------------------------------------------------

llvm-svn: 370445

llvm-svn: 370439

------------------------------------------------------------------------
r368164 | s.desmalen | 2019-08-07 14:41:38 +0200 (Wed, 07 Aug 2019) | 13 lines

[AArch64][WinCFI] Do not pair callee-save instructions in LoadStoreOptimizer

Prevent the LoadStoreOptimizer from pairing any load/store instructions with
instructions from the prologue/epilogue if the CFI information has encoded the
operations as separate instructions.  This would otherwise lead to a mismatch
of the actual prologue size from the size as recorded in the Windows CFI.

Reviewers: efriedma, mstorsjo, ssijaric

Reviewed By: efriedma

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

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

llvm-svn: 370438

------------------------------------------------------------------------
r370367 | kadircet | 2019-08-29 16:38:02 +0200 (Thu, 29 Aug 2019) | 13 lines

[clangd][NFC] Update background-index command line description

Summary:
We didn't change this in D64019 just in case we revert it back.
Deleting it now.

Reviewers: hokein, sammccall

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

Tags: #clang

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

llvm-svn: 370370

llvm-svn: 370366

llvm-svn: 370364

llvm-svn: 370362

llvm-svn: 370360

llvm-svn: 370358

llvm-svn: 370357

llvm-svn: 370356