On 16 Mar 2019, at 11:55, Aurelien Jarno <aure...@debian.org> wrote: > > Source: ktexteditor > Version: 5.54.0-1 > Severity: normal > Tags: patch > User: debian-ri...@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