PR 39677: Workaround for AMD Errata 147

[Richard Henderson <rth at redhat dot com>]

AMD guys, can we get a bit more clarification about the conditions under 
which this problem occurs?  In particular,

# ... the read-modify-write instruction (in the critical section) ...

while it's clear to me from the source code level what the end of the
critical section may be, namely

  __sync_lock_release (&lock)

this normally expands to

  mov $0, lock

Given the normal state of affairs, namely strong memory ordering, this 
is sufficient.  Is that true of this errata as well?  If not, I assume that

  lock; and $0, lock

will work.  If the mov is sufficient, how else can we recognize that 
we've exited the region following the lock acquire that could be 
affected by the bug?  For instance, can the timing issue happen across 
taken branches?  Returns?  Or is the *only* way to be sure that we've 
exited the buggy region to issue either an LFENCE or another LOCKed insn?

I'm temporarily abandoning the libgcc changes I posted last Friday in 
favor of working around the bug in pre-SSE2 processors by emitting

  lock; orl $0, (%esp)

which seems like it ought to work.  Though a more detailed answer to the 
previous question should clarify that.

Also, what -mtune= cpu types ought to include this workaround?  I've 
turned on the workaround for -mtune=generic and a (possibly random) 
selection of amd cpu names.  One can always use the -msync-needs-lfence 
option directly, of course.

Please have a look through the following patch.


r~

Attachment: d-39677-1
Description: Text document