Bug#924722: ktexteditor: symbols update for riscv64
On 16 Mar 2019, at 11:55, Aurelien Jarno <aurel32@debian.org> wrote:
>
> Source: ktexteditor
> Version: 5.54.0-1
> Severity: normal
> Tags: patch
> User: debian-riscv@lists.debian.org
> Usertags: riscv64
>
> Hi,
>
> ktexteditor currently fails to build on the riscv64 architecture due to
> differences on the symbols file, as can be seen on the following build
> log:
>
> https://buildd.debian.org/status/fetch.php?pkg=ktexteditor&arch=riscv64&ver=5.54.0-1&stamp=1552467392&raw=0
>
> The attached patch update the symbols file. It looks like riscv64
> behaves the same way than armel and mips64el, but I do not necessarily
> understand why. It would be nice if you can include it in the next
> upload.
FWIW, the non-optional (non-template instantiation) lines are down to the
default __gnu_cxx::_Lock_policy, which is defined as follows for multi-threaded
code:
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
However, riscv64 only has _4 and _8, which I assume is due to it only having
lr.w and lr.d. But, at the same time, this is also true for MIPS, which still
defines _1 and _2, expanding them to a masked compare-and-swap, so it seems to
me that GCC should be doing the same on riscv64 and that this is really a GCC
bug. The LLVM backend for RISC-V supports this just like for MIPS (though the
Clang frontend doesn't currently let you use atomics). Aurelien, thoughts?
James
Reply to: