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.
