Re: libstdc++/7926

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

> tested x86/linux

> Stops pretending that i386's atomicity.h ever existed, use generic. Arm,
> same. Use i486 for x86-64, and athlon. Remove extraneous bits.

I wondered why threading broke on ref5 over the weekend...  I think
something more complex will have to be done to fix this in a way that
doesn't break a common i386 port situation (i.e. a misreporting of the
real CPU in the system).

I am fairly unhappy with this change because of the number of PRs it
will produce in the future not because it is logically incorrect
(well, other than any port that is suppose to support threading yet
uses generic is a complete logical error IMHO).  It breaks
multi-threading on i386-unknown-freebsd[45] when the processor is
really something greater than an i386.  This is not uncommon since
FreeBSD, unlike Linux, always reports i386 via uname instead of a
dynamically-computed answer based on the CPU.  Now, I see that this is
a FreeBSD failing where we just got lucky since >99.9% of people using
FreeBSD/i386 actually use something more modern than an i386.  And
granted, I as a maintainer could start adding
``i[456]86-unknown-freebsd?.?'' on my configure line and I could
document this debacle in the i386-*-freebsd* section of install.texi.
However, I know already that this patch will cause much pain if ever
unleashed upon users in its current form.

Next point, even after considering the instruction that is not
available on i386 (I am not responsible for the current state of that
file and this was news to me), that file is closer to correct than
using plain generic since it uses a proper LOCK adornment (which was
legal on i386).  We now know it doesn't exist natively but the open
question is an atomic exchange and add operation constructible for
i386?  I don't know the answer but it seems reasonable to look for an
answer rather than just blow away the file as if it never existed.

On the PPC, an asm back-off loop had to be constructed to properly
implement this feature.  Why can't this be done here?

I don't know how portable the code segment is but FreeBSD/i386 does
have an atomic compare and set, thus it is possible for some i386
ports (whether it "works" on >i386 || SMP is unknown to me).

(written from scratch:)

static inline _Atomic_word 
__attribute__ ((__unused__))
__exchange_and_add (volatile _Atomic_word *__mem, int __val)
{
  register _Atomic_word __proposed_result;
  register _Atomic_word __proposed_new;
  do {
    __proposed_result = *__mem;
    __proposed_new = __proposed_result + __val;
  } while (!__atomic_cmpset (__mem, __proposed_result, __proposed_new));

  return __proposed_result;
}

(taken from i386/include/atomic.h, lightly edited to use our type abstraction:)

static __inline int
__atomic_cmpset(volatile _Atomic_word *dst, _Atomic_word exp, _Atomic_word src)
{
        _Atomic_word res = exp;

        __asm __volatile(
        "       pushfl ;                "
        "       cli ;                   "
        "       cmpl    %0,%2 ;         "
        "       jne     1f ;            "
        "       movl    %1,%2 ;         "
        "1:                             "
        "       sete    %%al;           "
        "       movzbl  %%al,%0 ;       "
        "       popfl ;                 "
        "# atomic_cmpset_int"
        : "+a" (res)                    /* 0 (result) */
        : "r" (src),                    /* 1 */
          "m" (*(dst))                  /* 2 */
        : "memory");

        return (res);
}

Code using the above protocol (or a bug-fixed version of it) may or
may not be compatible with code that uses the "LOCK; XADDL" protocol.
The change which brutely forces generic doesn't come close.

Regards,
Loren