https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |arm
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-02-21
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Besides of store data races the issue is that we seem to not know that a[k]
doesn't trap inside cond_store_replacement because we consider loads and stores
separately (as if the memory might be mapped readonly):
We need to be careful with loads
or stores, for instance a load might not trap, while a store would,
so if we see a dominating read access this doesn't mean that a later
write access would not trap. Hence we also need to differentiate the
type of access(es) seen.
??? We currently are very conservative and assume that a load might
trap even if a store doesn't (write-only memory). This probably is
overly conservative. */
Changing the testcase to do
unsigned *a;
void test(unsigned k, unsigned b) {
a[k] = 5;
if (b < a[k]) {
a[k] = b;
}
}
generates
test:
.LFB0:
.cfi_startproc
movl $5, %eax
cmpl $5, %esi
movl %edi, %edi
cmovnb %eax, %esi
movq a(%rip), %rax
movl %esi, (%rax,%rdi,4)
ret
