https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81316
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-07-17
CC| |amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Yes, it's a similar target-specific issue, and I've noticed it when writing a
patch for PR 80640. At least x86 and s390 exhibit it. Perhaps it's better to
fix it in the middle-end (i.e. expand) though, rather than require backends
DTRT.
I've submitted a partial patch for this issue here:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00786.html but at the moment both
remain unreviewed. It also wouldn't fix this testcase, because I didn't notice
that x86 used UNSPEC on the RHS (i.e. not the memory operand) of the store, so
I added compiler barriers only for loads (more reason to fix it in expand, I
guess).
(the testcase formally invokes undefined behavior by entering an infinite loop
without side effects)
