Merge version 1:9.0.1-13+rpi1 and 1:9.0.1-14 to produce 1:9.0.1-14+rpi1

Merge llvm-toolchain-9 (1:9.0.1-14) import into refs/heads/workingbranch

[PATCH] Prefer __vector over vector keyword for altivec

`vector' uses the keyword-and-predefine mode from gcc, while __vector is
reliably supported.

As a side effect, it also makes the code consistent in its usage of __vector.

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

Gbp-Pq: Name 3185c30c54d0af5bffbff3bcfd721668d086ff10.patch

[PATCH] [InstCombine] Fix big-endian miscompile of (bitcast (zext/trunc (bitcast)))

Summary:
optimizeVectorResize is rewriting patterns like:
  %1 = bitcast vector %src to integer
  %2 = trunc/zext %1
  %dst = bitcast %2 to vector

Since bitcasting between integer an vector types gives
different integer values depending on endianness, we need
to take endianness into account. As it happens the old
implementation only produced the correct result for little
endian targets.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=44178
Reviewers: spatel, lattner, lebedev.ri

Reviewed By: spatel, lebedev.ri

Subscribers: lebedev.ri, hiraditya, uabelho, llvm-commits

Tags: #llvm

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

(cherry picked from commit a9d6b0e5444741d08ff1df7cf71d1559e7fefc1f)

Gbp-Pq: Name f8e146f3430de3a6cd904f3f3f7aa1bfaefee14c.patch

[PATCH] Revert "[SCEV] add no wrap flag for SCEVAddExpr."

This reverts r366419 because the analysis performed is within the context of
the loop and it's only valid to add wrapping flags to "global" expressions if
they're always correct.

llvm-svn: 373184
(cherry picked from commit 58e8c793d0e43150a6452e971a32d7407a8a7401)

Gbp-Pq: Name 373184.patch

riscv64-multilib-empty

===================================================================

Gbp-Pq: Name riscv64-multilib-empty.patch

[PATCH] Fix sanitizer-common build with glibc 2.31

Summary:
As mentioned in D69104, glibc changed ABI recently with the [[ https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2f959dfe849e0646e27403f2e4091536496ac0f0| 2f959dfe ]] change.
D69104 dealt with just 32-bit ARM, but that is just one of the many affected architectures.
E.g. x86_64, i?86, riscv64, sparc 32-bit, s390 31-bit are affected too (and various others).

This patch instead of adding a long list of further architectures that wouldn't be checked ever next to arm 32-bit changes the structures to match the 2.31 layout and performs the checking on Linux for ipc_perm mode position/size only on non-Linux or on Linux with glibc 2.31 or later.  I think this matches what is done for aarch64 already.
If needed, we could list architectures that haven't changed ABI (e.g. powerpc), so that they would be checked even with older glibcs.  AFAIK sanitizers don't actually use ipc_perm.mode and
so all they care about is the size and alignment of the whole structure.

Note, s390 31-bit and arm 32-bit big-endian changed ABI even further, there will now be shmctl with old symbol version and shmctl@@GLIBC_2.31 which will be incompatible.  I'm afraid this isn't really solvable unless the sanitizer libraries are symbol versioned and use matching symbol versions to glibc symbols for stuff they intercept, plus use dlvsym.
This patch doesn't try to address that.

Patch by Jakub Jelinek.

Reviewers: kcc, eugenis, dvyukov

Reviewed By: eugenis

Subscribers: jyknight, kristof.beyls, fedor.sergeev, simoncook, PkmX, s.egerton, steven.zhang, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Gbp-Pq: Name 947f9692440836dcb8d88b74b69dd379d85974ce.patch

cgi method is deprecated, use html instead

Last-Update: 2020-02-25

Gbp-Pq: Name no-cgi.patch

print-lldb-path

Last-Update: 2020-01-21

Gbp-Pq: Name print-lldb-path.patch

change all shebangs to Python3

find . -name "*.py" -exec sed "s|\!/usr/bin/env python$|\!/usr/bin/env python3|g" -i {} \;

Gbp-Pq: Name python3-shebang.patch

[PATCH] [Mips] Add support for min/max/umin/umax atomics

In order to properly implement these atomic we need one register more than other
binary atomics. It is used for storing result from comparing values in addition
to the one that is used for actual result of operation.

https://reviews.llvm.org/D71028

Changed-by: James Clarke <jrtc27@debian.org>
[Backported to 9 by replacing Register with unsigned]

Gbp-Pq: Name D71028-mips-rust-test.diff

Disable z3 to avoid pulling ocaml into main.

For some reason the cmake option LLVM_ENABLE_Z3_SOLVER was not taken into account
Last-Update: 2019-11-26

Gbp-Pq: Name no-z3.patch

disable-fuzzer-compiler-rt

===================================================================

Gbp-Pq: Name disable-fuzzer-compiler-rt.diff

disable-lit-cpuid-install

===================================================================

Gbp-Pq: Name disable-lit-cpuid-install.diff

D67877

Origin: https://reviews.llvm.org/D67877
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941082

Gbp-Pq: Name D67877.patch

[PATCH] [LegalizeTypes][RISCV] Correctly sign-extend comparison for ATOMIC_CMP_XCHG

Summary:
Currently, the comparison argument used for ATOMIC_CMP_XCHG is legalised
with GetPromotedInteger, which leaves the upper bits of the value
undefind. Since this is used for comparing in an LR/SC loop with a
full-width comparison, we must sign extend it. We introduce a new
getExtendForAtomicCmpSwapArg to complement getExtendForAtomicOps, since
many targets have compare-and-swap instructions (or pseudos) that
correctly handle an any-extend input, and the existing function
determines the extension of the result, whereas we are concerned with
the input.

This is related to https://reviews.llvm.org/D58829, which solved the
issue for ATOMIC_CMP_SWAP_WITH_SUCCESS, but not the simpler
ATOMIC_CMP_SWAP.

Reviewers: asb, lenary, efriedma

Reviewed By: asb

Subscribers: arichardson, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, evandro, llvm-commits

Tags: #llvm

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

Gbp-Pq: Name D74453-riscv-atomic_cmp_xchg.diff

D60657-riscv-pcrel_lo

commit 41449c58c58e466bcf9cdc4f7415950382bad8d7
Author: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
Date:   Fri Nov 8 08:26:30 2019 +0000

    [RISCV] Fix evaluation of %pcrel_lo

    The following testcase

      function:
      .Lpcrel_label1:
            auipc   a0, %pcrel_hi(other_function)
            addi    a1, a0, %pcrel_lo(.Lpcrel_label1)
            .p2align        2          # Causes a new fragment to be emitted

            .type   other_function,@function
      other_function:
            ret

    exposes an odd behaviour in which only the %pcrel_hi relocation is
    evaluated but not the %pcrel_lo.

      $ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump  -d -r -

      <stdin>:      file format ELF64-riscv

      Disassembly of section .text:
      0000000000000000 function:
             0:     17 05 00 00     auipc   a0, 0
             4:     93 05 05 00     mv      a1, a0
                    0000000000000004:  R_RISCV_PCREL_LO12_I other_function+4

      0000000000000008 other_function:
             8:     67 80 00 00     ret

    The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we
    only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
    consider the section. This usually works but there are cases where the
    section may still be the same but the fragment may be another one. In
    that case we end forcing a %pcrel_lo relocation without any %pcrel_hi.

    This patch makes RISCVAsmBackend::shouldForceRelocation use the section,
    if any, to determine if the relocation must be forced or not.

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

Gbp-Pq: Name D60657-riscv-pcrel_lo.diff

llvm-riscv64-fix-cffi

commit c6b09bff5671600f8e764d3847023d0996f328d9
Author: Luís Marques <luismarques@lowrisc.org>
Date:   Thu Nov 14 18:27:42 2019 +0000

    [RISCV] Fix wrong CFI directives

    Summary: Removes CFI CFA directives that could incorrectly propagate
    beyond the basic block they were inteded for. Specifically it removes
    the epilogue CFI directives. See the branch_and_tail_call test for an
    example of the issue. Should fix the stack unwinding issues caused by
    the incorrect directives.

    Reviewers: asb, lenary, shiva0217
    Reviewed By: lenary
    Tags: #llvm
    Differential Revision: https://reviews.llvm.org/D69723

Gbp-Pq: Name llvm-riscv64-fix-cffi.diff

clang-riscv64-rv64gc

===================================================================

Gbp-Pq: Name clang-riscv64-rv64gc.diff

clang-riscv64-multiarch

===================================================================

Gbp-Pq: Name clang-riscv64-multiarch.diff

bootstrap-fix-include-next

When doing a bootstrap, we use a newly built clang.
When this one is used, if already installed on the system,
we have clang header in two places:
llvm-toolchain-7-7/build-llvm/lib/clang/7.0.0/include/inttypes.h
and
/usr/include/clang/7.0.0/include/inttypes.h

Because clang expects only one of his headers to be available, it uses
include_next to get the glibc (libc6-dev package) header.

However, in the previous example, because we have inttypes.h twice in the
include search path, clang's header will call itself without any effect.
Therefore, it will do include_next until the define from the libc is existing (ex: _INTTYPES_H)

Gbp-Pq: Name bootstrap-fix-include-next.diff

arm

===================================================================

Gbp-Pq: Name 930008-arm.diff

hurd-cxx-paths

hurd: find c++ headers

This should be factorized with Linux.cpp and the GNU/kFreeBSD case.

Gbp-Pq: Topic hurd
Gbp-Pq: Name hurd-cxx-paths.diff

impl-path-hurd

===================================================================

Gbp-Pq: Topic hurd
Gbp-Pq: Name impl-path-hurd.diff

hurd-pathmax

===================================================================

Gbp-Pq: Topic hurd
Gbp-Pq: Name hurd-pathmax.diff

Use Debian-provided MathJax everywhere.

Gbp-Pq: Name 0049-Use-Debian-provided-MathJax-everywhere.patch

remove-apple-clang-manpage

===================================================================

Gbp-Pq: Name remove-apple-clang-manpage.diff

clangd-atomic-cmake

===================================================================

Gbp-Pq: Name clangd-atomic-cmake.patch

clang-arm-default-vfp3-on-armv7a

===================================================================

Gbp-Pq: Name clang-arm-default-vfp3-on-armv7a.patch

disable-sse2-old-x86

===================================================================

Gbp-Pq: Name disable-sse2-old-x86.diff

clang-baseline-fix-i386

===================================================================

Gbp-Pq: Name clang-baseline-fix-i386.patch

set correct float abi settings for armel and armhf

debian armel supports systems that don't have a fpu so should use a "float abi"
setting of soft by default.

Debian armhf needs a float abi setting of "hard"

Gbp-Pq: Name 26-set-correct-float-abi.diff

mips-force-nomadd4

The MIPS port aims to support the Loongson 3 family of CPUs in addition
of the other MIPS CPUs. On the Loongson 3 family the MADD4 instructions
are fused, while they are not fused on the other MIPS CPUs. In order to
support both, we have to disabled those instructions.

For that, the patch below basically corresponds to the --with-madd4=no
used on the GCC side.

Gbp-Pq: Name mips-force-nomadd4.diff

mips-fpxx-enable

===================================================================

Gbp-Pq: Name mips-fpxx-enable.diff

libcxx-silent-failure-arm64

===================================================================

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-silent-failure-arm64.diff

libcxx-silent-failure-ppc64el

===================================================================

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-silent-failure-ppc64el.diff

libcxx-silent-test-libcxx

===================================================================

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-silent-test-libcxx.diff

libcxx-test-atomics-set-compare-exchange-to-be-expected-fails-on-arm

Clang 3.9 regression causes a bug when generating code for
std::atomic_compare_and_exchange*(std::atomic<long long>,...) without
optimizations. If same code is compiled with -O2 tests pass without problems.
Atomics are implement in headers with builtin functions which makes this
affect application code instead of libc++ library code.

libcxx tests default to -O0 compilation so these test need to be marked failing
on arm to allow installing packages. Use cases is so borderline failure that it
shouldn't prevent building the package. (64bit atomics in 32bit mode)

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-test-atomics-set-compare-exchange-to-be-expected-fails-on-arm.patch

libcxxabi-arm-ehabi-fix

Fix arm EHABI code to work. armhf had exception test failing without EHABI support.

No known upstream bug about this. Actual code change is more like workaround than
something that upstream would accept. Proper fix would be adding _Unwind_Control_Block
to clang unwind.h. _Unwind_Control_Block should also extend _Unwind_Exception to make
sure their ABI stays in sync.

No known upstream bug about this.

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxxabi-arm-ehabi-fix.patch

libcxx-test-fix-lockfree-test-for-i386

Lock is_always_lock free test fails on i386 because std::atomic is aligned

Lock is_always_lock free test fails on i386 because std::atomic is aligned
to 8 bytes while long long is aligned to 4 bytes. clang can't generate inline
code for unaligned 8 byte atomics even tough instruction set and gcc support
it.

That makes it expected thaqt ATOMIC_LLONG_LOCK_FREE and
std::atomic<long long>::is_always_lock_free don't match on i386. Correct test
for std::atomic<long long> is to check if target cpu support cmpxchg8 instruction.
To set instruction support one can check __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 define.

Bug: https://llvm.org/bugs/show_bug.cgi?id=19355

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxx-test-fix-lockfree-test-for-i386.patch

libcxxabi-test-don-t-fail-extended-long-double

Powerpc has extended double that doesn't match x86 coding. Power format would
need special tests to verify correctness but for now it is enough to prevent
incorrect test from running.

Gbp-Pq: Topic libcxx
Gbp-Pq: Name libcxxabi-test-don-t-fail-extended-long-double.patch

bootstrap-with-openmp-version-export-missing

===================================================================

Gbp-Pq: Topic openmp
Gbp-Pq: Name bootstrap-with-openmp-version-export-missing.diff

openmp-mips-affinity

===================================================================

Gbp-Pq: Topic openmp
Gbp-Pq: Name openmp-mips-affinity.patch

openmp-check-execstack

===================================================================

Gbp-Pq: Topic openmp
Gbp-Pq: Name openmp-check-execstack.diff

disable-error-xray

===================================================================

Gbp-Pq: Name disable-error-xray.diff

lldb-disable-swig-error

===================================================================

Gbp-Pq: Topic lldb
Gbp-Pq: Name lldb-disable-swig-error.diff

lldb-missing-install

===================================================================

Gbp-Pq: Topic lldb
Gbp-Pq: Name lldb-missing-install.diff

lldb-addversion-suffix-to-llvm-server-exec

lldb-server exec users always /usr/bin/lldb-server. Server is required
for any debugging with lldb which makes it unusable unless default version
package has been installed. Small changes to code and debian/rules allows
a workaround for lldb-server start up.

To use this one needs to add cmake definition during configure. eg
-DDEBIAN_VERSION_SUFFIX=-$(LLVM_VERSION)

Better implementation would be to use /usr/share/llvm-$(VERSION)/bin but
that change seems to require a big change to the path handling code
which could then break something else.

This probably should have upstream bug but I couldn't find any existing report.

Gbp-Pq: Topic lldb
Gbp-Pq: Name lldb-addversion-suffix-to-llvm-server-exec.patch

Link with -latomic when mips* processor is detected

Last-Update: 2016-07-27

Gbp-Pq: Topic lldb
Gbp-Pq: Name lldb-link-atomic-cmake.patch

fix-scan-view-path

===================================================================

Gbp-Pq: Name fix-scan-view-path.diff

scan-view-fix-path

===================================================================

Gbp-Pq: Name scan-view-fix-path.diff

install-scan-build-py

Gbp-Pq: Name install-scan-build-py.diff

scan-build-clang-path

Gbp-Pq: Name scan-build-clang-path.diff

test-keep-alive

===================================================================

Gbp-Pq: Name test-keep-alive.diff

disable-path-test-failing

===================================================================

Gbp-Pq: Name disable-path-test-failing.diff

Silent a test failing on yakkety amd64

Last-Update: 2016-08-26

/tmp/buildd/llvm-toolchain-snapshot-4.0~svn279801/test/tools/llvm-symbolizer/print_context.c:16:11: error: expected string not found in input
// CHECK: inc
         ^
<stdin>:1:1: note: scanning from here
_fini
^
<stdin>:1:3: note: possible intended match here
_fini
 ^

Gbp-Pq: Name disable-llvm-symbolizer-test.diff

remove-test-freezing

===================================================================

Gbp-Pq: Name remove-test-freezing.diff

silent-llvm-isel-fuzzer

===================================================================

Gbp-Pq: Name silent-llvm-isel-fuzzer.diff

silent-test-macho

===================================================================

Gbp-Pq: Name silent-test-macho.diff

silent-amd-tet

===================================================================

Gbp-Pq: Name silent-amd-tet.diff

silent-test-failing-codeverage

===================================================================

Gbp-Pq: Name silent-test-failing-codeverage.diff

silent-gold-utils

Gbp-Pq: Name silent-gold-utils.diff

silent-MCJIIT-tests

Gbp-Pq: Name silent-MCJIIT-tests.diff

silent-more-tests

# Comment the tests for the code coverage (fails otherwise)

Gbp-Pq: Name silent-more-tests.diff

fails on debian unstable amd64

Command Output (stderr):
--
/build/llvm-toolchain-snapshot-4.0~svn279916/llvm/test/tools/gold/X86/start-lib-common.ll:22:10: error: expected string not found in input
; CHECK: @x = common global i32 0, align 8
         ^
<stdin>:1:1: note: scanning from here
; ModuleID = '/build/llvm-toolchain-snapshot-4.0~svn279916/build-llvm/llvm/test/tools/gold/X86/Output/start-lib-common.ll.tmp3.o'
^
<stdin>:4:1: note: possible intended match here
@x = common global i32 0, align 4
^

Gbp-Pq: Name silent-gold-test.diff

openmp-soname

===================================================================

Gbp-Pq: Name openmp-soname.diff

lldb-libname

Gbp-Pq: Name lldb-libname.diff

lldb-soname

Gbp-Pq: Name lldb-soname.diff

soname

Gbp-Pq: Name 0044-soname.diff

[PATCH] [llvm] cmake: resolve symlinks in LLVMConfig.cmake

Ensure that symlinks such as /usr/lib/llvm-X.Y/cmake (pointing to
lib/cmake/llvm) are resolved. This ensures that LLVM_INSTALL_PREFIX
becomes /usr/lib/llvm-X.Y instead of /usr.

Partially addresses PR37128

Gbp-Pq: Name 0001-llvm-cmake-resolve-symlinks-in-LLVMConfig.cmake.patch

fix-llvm-config-obj-src-root

Gbp-Pq: Name fix-llvm-config-obj-src-root.patch

disable-display-PASS-UNSUPPORTED-XFAIL

===================================================================

Gbp-Pq: Name disable-display-PASS-UNSUPPORTED-XFAIL.diff

do-not-fail-on-unexpected-pass

===================================================================

Gbp-Pq: Name do-not-fail-on-unexpected-pass.diff

debug-jit-path

===================================================================

Gbp-Pq: Name debug-jit-path.diff

[PATCH] [clang] cmake: resolve symlinks in ClangConfig.cmake

Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to
/usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that
CLANG_INSTALL_PREFIX ends up to be /usr/lib/llvm-X.Y instead of /usr.

Partially addresses PR37128

Gbp-Pq: Name 0001-tools-clang-cmake-resolve-symlinks-in-ClangConfig.cmake.patch

clang-tidy-run-bin

===================================================================

Gbp-Pq: Name clang-tidy-run-bin.diff

symbolizer-path

===================================================================

Gbp-Pq: Name symbolizer-path.diff

Set html_static_path = ['_static'] everywhere.

Gbp-Pq: Name 0048-Set-html_static_path-_static-everywhere.patch

fix-clang-path-and-build

===================================================================

Gbp-Pq: Name fix-clang-path-and-build.diff

python-clangpath

Gbp-Pq: Name python-clangpath.diff

atomic_library_1

Gbp-Pq: Name atomic_library_1.diff

unwind-chain-inclusion

# Without this patch, the first local include of unwind.h might, with the
# __has_include_next, try to include the one from the system.
# It might be /usr/include/clang/3.4/include/unwind.h
# Because of the #ifndef __CLANG_UNWIND_H, it might never include any declaration
# from the system.

Gbp-Pq: Name unwind-chain-inclusion.diff

declare_clear_cache

Gbp-Pq: Name declare_clear_cache.diff

strlcpy_strlcat_warning_removed

Gbp-Pq: Name 23-strlcpy_strlcat_warning_removed.diff

clang-analyzer-force-version

# Force the version of clang in the analyzer
# This was causing the static analyzer to fail silently if the clang & clang++ are
# not installed

Gbp-Pq: Name clang-analyzer-force-version.diff

clang-format-version

Gbp-Pq: Name clang-format-version.diff

Debian-version-info-and-bugreport

Gbp-Pq: Name 0003-Debian-version-info-and-bugreport.patch

clang_debian_version

===================================================================

Gbp-Pq: Name 19-clang_debian_version.patch

llvm-toolchain-9 (1:9.0.1-14) unstable; urgency=medium

  * debian/patches/b288d90b39f4b905c02092a9bfcfd6d78f99b191.patch:
  * debian/patches/3185c30c54d0af5bffbff3bcfd721668d086ff10.patch:
    - cherry-pick upstream fixes for ppc64el build failure (Closes: #968174)
  * Previous version closed bug: 964988 (Closes: #964988)

[dgit import unpatched llvm-toolchain-9 1:9.0.1-14]

Import llvm-toolchain-9_9.0.1-14.debian.tar.xz

[dgit import tarball llvm-toolchain-9 1:9.0.1-14 llvm-toolchain-9_9.0.1-14.debian.tar.xz]

Merge version 1:9.0.1-12+rpi1 and 1:9.0.1-13 to produce 1:9.0.1-13+rpi1

Merge llvm-toolchain-9 (1:9.0.1-13) import into refs/heads/workingbranch

[PATCH] [InstCombine] Fix big-endian miscompile of (bitcast (zext/trunc (bitcast)))

Summary:
optimizeVectorResize is rewriting patterns like:
  %1 = bitcast vector %src to integer
  %2 = trunc/zext %1
  %dst = bitcast %2 to vector

Since bitcasting between integer an vector types gives
different integer values depending on endianness, we need
to take endianness into account. As it happens the old
implementation only produced the correct result for little
endian targets.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=44178
Reviewers: spatel, lattner, lebedev.ri

Reviewed By: spatel, lebedev.ri

Subscribers: lebedev.ri, hiraditya, uabelho, llvm-commits

Tags: #llvm

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

(cherry picked from commit a9d6b0e5444741d08ff1df7cf71d1559e7fefc1f)

Gbp-Pq: Name f8e146f3430de3a6cd904f3f3f7aa1bfaefee14c.patch

[PATCH] Revert "[SCEV] add no wrap flag for SCEVAddExpr."

This reverts r366419 because the analysis performed is within the context of
the loop and it's only valid to add wrapping flags to "global" expressions if
they're always correct.

llvm-svn: 373184
(cherry picked from commit 58e8c793d0e43150a6452e971a32d7407a8a7401)

Gbp-Pq: Name 373184.patch

riscv64-multilib-empty

===================================================================

Gbp-Pq: Name riscv64-multilib-empty.patch

[PATCH] Fix sanitizer-common build with glibc 2.31

Summary:
As mentioned in D69104, glibc changed ABI recently with the [[ https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2f959dfe849e0646e27403f2e4091536496ac0f0| 2f959dfe ]] change.
D69104 dealt with just 32-bit ARM, but that is just one of the many affected architectures.
E.g. x86_64, i?86, riscv64, sparc 32-bit, s390 31-bit are affected too (and various others).

This patch instead of adding a long list of further architectures that wouldn't be checked ever next to arm 32-bit changes the structures to match the 2.31 layout and performs the checking on Linux for ipc_perm mode position/size only on non-Linux or on Linux with glibc 2.31 or later.  I think this matches what is done for aarch64 already.
If needed, we could list architectures that haven't changed ABI (e.g. powerpc), so that they would be checked even with older glibcs.  AFAIK sanitizers don't actually use ipc_perm.mode and
so all they care about is the size and alignment of the whole structure.

Note, s390 31-bit and arm 32-bit big-endian changed ABI even further, there will now be shmctl with old symbol version and shmctl@@GLIBC_2.31 which will be incompatible.  I'm afraid this isn't really solvable unless the sanitizer libraries are symbol versioned and use matching symbol versions to glibc symbols for stuff they intercept, plus use dlvsym.
This patch doesn't try to address that.

Patch by Jakub Jelinek.

Reviewers: kcc, eugenis, dvyukov

Reviewed By: eugenis

Subscribers: jyknight, kristof.beyls, fedor.sergeev, simoncook, PkmX, s.egerton, steven.zhang, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Gbp-Pq: Name 947f9692440836dcb8d88b74b69dd379d85974ce.patch

cgi method is deprecated, use html instead

Last-Update: 2020-02-25

Gbp-Pq: Name no-cgi.patch

print-lldb-path

Last-Update: 2020-01-21

Gbp-Pq: Name print-lldb-path.patch

change all shebangs to Python3

find . -name "*.py" -exec sed "s|\!/usr/bin/env python$|\!/usr/bin/env python3|g" -i {} \;

Gbp-Pq: Name python3-shebang.patch

[PATCH] [Mips] Add support for min/max/umin/umax atomics

In order to properly implement these atomic we need one register more than other
binary atomics. It is used for storing result from comparing values in addition
to the one that is used for actual result of operation.

https://reviews.llvm.org/D71028

Changed-by: James Clarke <jrtc27@debian.org>
[Backported to 9 by replacing Register with unsigned]

Gbp-Pq: Name D71028-mips-rust-test.diff