On 30/04/19 21:06 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote:
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek <ja...@redhat.com> wrote:
> From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and
> swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit
> cas using 32 bit one).
This is a known problem on our to do list, and there is already a
bugzilla or two about this. There are unfortunately a lot of items on
our to do list as RISC-V is still a relatively new target. This is
also complicated by the fact that we didn't have a formal memory model
defined until last year, and now that we do have one, the gcc support
needs to be updated to follow the formal memory model. There are a
number of cleanup issues to fix here, such as the fact that we are
emitting fences in places where the formal memory model says we don't
need them. Anyways, we do want to fix this, but it is not clear when
we will have time to do it.
I think you can e.g. have a look at what alpha does in
alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit
compare and swap either.
Anyway, once you make a change, there will need to be work on the libstdc++
side for riscv too to preserve ABI (i.e. keep exporting the _Lock_priority 1
variants and add _Lock_priority 2 to a new symbol version).
Or to make the directory iterators keep using the same type as used
today, __shared_ptr<T, _S_mutex>, even if the _S_atomic policy would
work instead.
