Bug#924722: ktexteditor: symbols update for riscv64

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#924722: ktexteditor: symbols update for riscv64

Aurelien Jarno-2
Source: ktexteditor
Version: 5.54.0-1
Severity: normal
Tags: patch
User: [hidden email]
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.

Thanks,
Aurelien

ktexteditor_5.54.0-1_riscv64.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#924722: ktexteditor: symbols update for riscv64

James Clarke-2
On 16 Mar 2019, at 11:55, Aurelien Jarno <[hidden email]> wrote:

>
> Source: ktexteditor
> Version: 5.54.0-1
> Severity: normal
> Tags: patch
> User: [hidden email]
> 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