public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/42869]  New: GOMP_critical_start wrong on Itanium due to __sync miscompilation
@ 2010-01-26  2:12 Hans dot Boehm at hp dot com
  2010-01-26 12:06 ` [Bug target/42869] " rguenth at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: Hans dot Boehm at hp dot com @ 2010-01-26  2:12 UTC (permalink / raw)
  To: gcc-bugs

The Itanium code for GOMP_start_critical starts 

0x2000000000334900 <GOMP_critical_start>:
    [MMI]       alloc r16=ar.pfs,1,1,0
0x2000000000334901 <GOMP_critical_start+1>:                 addl r32=840,r1
0x2000000000334902 <GOMP_critical_start+2>:                 nop.i 0x0
0x2000000000334910 <GOMP_critical_start+16>:    [MMI]       mf;;
0x2000000000334911 <GOMP_critical_start+17>:                mov.m ar.ccv=0
0x2000000000334912 <GOMP_critical_start+18>:                mov r14=1;;
0x2000000000334920 <GOMP_critical_start+32>:    [MMI]       nop.m 0x0
0x2000000000334921 <GOMP_critical_start+33>:
                cmpxchg4.rel r14=[r32],r14,ar.ccv
0x2000000000334922 <GOMP_critical_start+34>:                nop.i 0x0;;
0x2000000000334930 <GOMP_critical_start+48>:    [MIB]       nop.m 0x0
0x2000000000334931 <GOMP_critical_start+49>:                cmp.eq p6,p7=0,r14
0x2000000000334932 <GOMP_critical_start+50>:
          (p06) br.ret.dptk.many b0;;

Note the mf followed by a cmxchg4.rel.  I don't believe this enforces
sufficient memory ordering constraints.  A subsequent store from inside the
critical section may become visible to other threads before the cmpxchg4.rel,
which is only intended to prevent reordering in the OTHER direction.  Thus a
store inside the critical section can become visible before the lock is really
acquired, which is, at least theoretically, very bad.

I do not know whether current hardware may actually execute these out of order.
 I observed this while trying to understand the GNU OpenMP support.  I also
don't know whether this problem is limited to Itanium.  I expect it doesn't
exist on X86.  It may exist onother weakly-ordered architectures.

I believe that this is due to incorrect code generated for the
__sync_bool_compare_and_swap in gomp_mutex_lock().


-- 
           Summary: GOMP_critical_start wrong on Itanium due to __sync
                    miscompilation
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Hans dot Boehm at hp dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-07-21 22:38 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-26  2:12 [Bug c/42869] New: GOMP_critical_start wrong on Itanium due to __sync miscompilation Hans dot Boehm at hp dot com
2010-01-26 12:06 ` [Bug target/42869] " rguenth at gcc dot gnu dot org
2010-03-09 23:25 ` sje at cup dot hp dot com
2010-03-09 23:33 ` jakub at gcc dot gnu dot org
2010-03-09 23:49 ` sje at cup dot hp dot com
2010-03-12 18:19 ` sje at gcc dot gnu dot org
2010-03-12 18:23 ` sje at cup dot hp dot com
2010-07-21 22:38 ` sje at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).