This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: atomic_thread_fence() semantics
On Fri, 2017-10-20 at 18:46 +0300, Alexander Monakov wrote:
> On Fri, 20 Oct 2017, Torvald Riegel wrote:
> > On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote:
> > > On Thu, 19 Oct 2017, Andrew Haley wrote:
> > > > No, you did not. This looks like a bug. Please report it.
> > >
> > > This bug is fixed on trunk, so should work from gcc-8 onwards (PR 80640).
> >
> > The test case is invalid (I added some more detail as a comment on this
> > bug).
>
> Sorry, I was imprecise. To be clear, the issue I referred to above as the
> "bug [that was] fixed on trunk" is the issue Andrew Haley pointed out: when
> GCC transitioned from GIMPLE to RTL IR, empty RTL was emitted for the fence
> statement, losing its compile-time effect as a compiler memory barrier entirely.
What I tried to convey was that I think this can be a (part of a) valid
implementation on certain hardware, and when considering C11/C++11 or
more recent, which require programs to not have any data races (as
defined by these standards).