[llvm-dev] O2 Aggressive Optimization by GCC

[Tim Northover via llvm-dev]

On Fri, 20 Jul 2018 at 13:20, Umesh Kalappa via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Anyone from the community ,please share their insights why above
> transformation is right ?

In addition to the UB you mentioned yourself, there's no way any other
thread could detect that j has been modified without introducing a
race (because this thread doesn't do any synchronization and j is
non-atomic).

I sort of doubt that the optimizer is making use of that fact because
it's very hard in general to prove that no synchronization occurs
elsewhere. But it should probably give you pause over just what you're
trying to do.

> and without using volatile or memory barrier ,how we can stop the
> above transformation.

You could use a (possibly memory_order_relaxed) atomic operation to
store to j. That would then be something the compiler has to ensure
reaches other threads.

Cheers.

Tim.