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

[Loren James Rittle]

>Bummer, bits/atomicity.h is publically used? How that?

<bits/atomicity.h> is included in C++ headers which may be included by
user programs.  The implementation exposed in <bits/atomicity.h> is
used to implement templated stuff visible (i.e. pulled into) object
files.

> I do not understand. The patch addresses gcc-3.2.x and contains parts
> from current gcc-3.2-branch, only.

I am indeed sorry but no patches are accepted for the 3.2 branch
effective the release of gcc 3.2.3 last week.  I understand the points
you have been making better now.  FYI, SOP around here is to look at
gcc mainline, fix the bug there and then back port to branches that
still need a fix/can take a fix without an ABI change.  I am sorry I
misunderstood that you are looking at a root bug fixed on mainline at
the end of 2002.  It was ported to/appears on the 3.3 branch only
since no reasonable fix for the 3.2 branch was ever found.

At the time the i386/atomicity.h file was killed due to incorrect use
of an i486 instruction, a major thread ensued:

http://gcc.gnu.org/ml/libstdc++/2002-11/msg00023.html

> => If what you say holds and if I understand correctly, the generic
> implementation in gcc-3.2.x is broken.

Indeed, it was.

>> I much rather prefer the patch that Joel
>> posted (this is where we find a spin lock implementation that works on
>> i386 and all architectures which claim compatibility with i386/IA32).

> How about using an external global c-function (or extern static
> C++-function) or pointer to such function instead?

> Then such #ifdefs could be used inside of the library could be
> transparently hidden from user-code.

Yes.  A patch against gcc mainline that affected this change, and was
tested for a multiple ports of interest, would probably be accepted.
The window to make this major change before gcc 3.3 ships is near
closed, but could be justified as a proper bug fix.

Regards,
Loren