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

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

llvm-svn: 371964

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

LDC, the LLVM-based D compiler, is already ready for LLVM 9.0.0.

llvm-svn: 372167

This is needed for `-C target-cpu=help` and `-C target-feature=help` in rustc

If this lines are present then we apparently get errors [1] when compiling in
the current [2] dist-i686-linux container. Attempts to upgrade both gcc and
binutils did not fix the error, so it appears that this may just be a bug in the
super old glibc we're using on the dist-i686-linux container.

We don't actually need this code anyway, so just work around these issues by
removing references to the `*64` functions. This'll get things compiling
locally and shouldn't be a regression in functionality.

[1]: https://travis-ci.org/rust-lang/rust/jobs/257578199
[2]: https://github.com/rust-lang/rust/tree/eba9d7f08ce5c90549ee52337aca0010ad566f0d/src/ci/docker/dist-i686-linux

For whatever reason this is failing the i686-freebsd builder in the Rust repo
as-of this red-hot moment. The build seems to work fine without it so let's just
remove it for now and pray there's a better fix later.

Although if you're reading this and know of a better fix, we'd love to remove
this!

Apparently glibc is so old it doesn't have the _POSIX_ARG_MAX constant. This
shouldn't affect anything we use anyway though.

https://travis-ci.org/rust-lang/rust/jobs/399333071

Can't seem to figure out how to do this without this patch...

It's not entertirely clear why this is necessary but this is carrying
over an old `compiler-rt` patch to ensure that `compiler-rt` compiles in
our super ancient containers that we build sanitizers in. This ideally
isn't the worst thing to keep with us going forward, but we'll see!

Define it to 0 if it doesn't exist.

__builtin_available() pulls in __isOSVersionAtLeast() from
compiler-rt. Comment it out so we don't have to figure out how
to pull in this symbol...

…lyExplicitLocals pass

Extends DWARF expression larguage to express locals/globals locations. (via
target-index operands)

The WebAssemblyExplicitLocals can replace virtual registers to target-index()
operand type at the time when WebAssembly backend introduces local.{get,set,tee}
instead of corresponding virtual registers.

Reviewers: aprantl, dschuff

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