[Bug other/68616] New: miscompilation in multi-threaded code

["torvald at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68616

            Bug ID: 68616
           Summary: miscompilation in multi-threaded code
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: torvald at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36871&action=edit
test case

In the attached case, the compiler seems to assume that in main_thread, ptr
still points to x despite there being a call to arrive_and_wait that contains
synchronization.  The compiled code on x86_64 with -O1 has just an
unconditional store to x after the arrive_and_wait call.  It must keep the
conditional because in fact the interference function waits for arrive_and_wait
to increment barrier, then assigns zero to ptr, and the unblocks
arrive_and_wait, which returns to main_thread.  So, in a correct execution,
main_thread will always see ptr==0 and do not assign to x.

This may or may not be a duplicate of PR 68591; I don't know so I created a new
PR.  Also, while just a transactional memory bug may be considered less severe,
this one here is a severe problem for multi-threaded code.

Also note that in a variation of this I didn't see the miscompilation: In that
case, main_thread() was a part of main() and the pthread_create call for
interference() was directly before the arrive_and_wait.  The code generated for
that case had the load and check of ptr before assigning to ptr.