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
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
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
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
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
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
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
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
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
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
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
/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
^
Last-Update: 2016-08-26
Gbp-Pq: Name disable-llvm-symbolizer-test.diff
Gianfranco Costamagna