Re: gcc 3.2.3 config/os/bits/i386/atomicity.h broken

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <3EA93D8A dot C9A4440B at OARcorp dot com> Joel Sherrill writes:

Joel, I don't know if you've been reading the list but you are a
godsend (maybe ;-).

> This area of libstdc++-v3 appears to have had significant
> work after the 3.2 branch was cut so I don't know if this
> bug is still there.  

> This file uses instructions which are not available on a
> plain i386.  

True, this bug was not fixed on the 3.2 branch (timing of ABI change).
Your analysis of prohibited instructions on i386 is all right AFAIK.

> static inline _Atomic_word
> __attribute__ ((__unused__))
> __exchange_and_add (volatile _Atomic_word *__mem, int __val)
> {
>  register _Atomic_word __result, __tmp;
>  static volatile _Atomic_word __lock = 1;
>
> /* obtain the atomic exchange/add lock */
>  do {
>    __tmp = 0;
>    __asm__ __volatile__("xchgl %0,%1"
>             :"=r" (__tmp)
>             :"m" (&__lock), "0" (__lock)
>             :"memory");
>  } while ( __tmp == 0 );
>  
>    __result = *__mem;
>    *__mem += __val;
>  
>  /* release spin lock */
>  __lock = 1;
>
>  return __result;
> }

> As best I can tell, in gcc 3.3 and later, there is no support
> for atomicity.h on the basic i386 at all.  Is this right?
> If this implementation works, could it be conditionally used
> in the x86 atomicity.h for the vanilla i386 and included
> in the single file?

Does the above implementation work if the processor is: i486, i586,
i686, Athlon, etc?  Does it work in SMP configurations of the higher
processors?  If you think that the answer to both questions are
unqualified "yes", then it could be used as a replacement for the old
bad code in i386/atomicity.h.  If it only works for single-processor
i386 systems then the generic code must remain as various UNIX systems
configure as i386-*-* even when they have high-end CPUs.  I have
googled on "xchgl avoid" and read the results.  Looks promising; as I
have desired to not ship generic code for i386 in any release.

This strongly implied that any architecture, SMP or single processor,
in the IA32 family would handle your code correctly:

  http://www.wlug.org.nz/HowToParallelProcessingHOWTO

However, the patch within implies to me that plain xchgl will fail on
x86-64 (would a compiler configured as i386-*-* be expected to support
x86-64? was the patch pessimistic?):

  http://www.x86-64.org/lists/discuss/msg01969.html

(The reason, I'm questioning above, is because I don't know.  I recall
that the 68K weakened the strength of TAS between 000 and 0[12]0 when
they added support for MP and a new bus locking protocol.  But that
was a lifetime ago.)

The regression in performance on configured-as i386-* but really
i686-* machines has been measurable on both 3.3 and mainline.

This does not fix the ABI issue raised in my response to Matthias.  In
fact, we need to be careful not to remove the link error, when we
apply your change.

Joel, are you willing and able to post a complete updated version of
config/cpu/i386/atomicity.h?  If the code was reviewed by enough
people, I'd really want to see it get into 3.3.

Regards,
Loren