https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80817
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
In the second example it's correct that lock;addq is generated, the
read-modify-write operation still needs to be atomic itself,
memory_order_relaxed indicates that it does not imply an order with respect to
other memory operations.
The first example could only be optimized on RTL level (on gimple there's no
memory rmw operations), but on RTL atomic accesses are represented as unspecs
or volatile accesses (they can't be plain accesses because the compiler may not
tear them etc, but there's no special RTL for atomic access, so volatile MEM is
the best fit), so on RTL it's similar to how
void f(volatile int *p)
{
++*p;
}
is not optimized either (and the issue is visible only on cisc-ish targets with
composite memory read-modify-write instructions, otherwise the load and store
would be separate anyway).
