Re: libstdc++/7926

[Benjamin Kosnik <bkoz at redhat dot com>]

>This has been broken since gcc 3.0 shipped and this is the first PR.
>Given the numbers involved, it is better to document that pure i386
>machines are basically hosed when it comes to threading support in
>libstdc++-v3 until gcc 3.3 is released.

Longer. I went back to 2.90.8 before I realized that i386 support was
never done.

"Basically hosed" is right. This might be something to fix, I think. Far
more  alarming than i386, to me, is arm. Ouch.

I don't think this patch should go on the the branch, especially not in
the current form. However, I do think it is the right thing to do, even
if it is unpleasant and makes some ports face up to hardware
limitations. I think it's a poor idea to have a i386 assembly file that
explicitly uses instructions that do not exist.

I like the idea of a generic locking mechanism that can be used. I think
this can be added later, when it gets developed.

Loren, I don't know i386 asm so I'll pass on your suggested patch. It sounds
promising, but the x86 maintainer should ok it. I suggest getting some
feedback from those folks. 

It would be nice to have distributions ship both an i386 and i686
libstdc++, to be used as appropriate. I'm not quite sure how to best
suggest that though, since it's more than the library binary that would
be different (although it wouldn't be that difficult, since this stuff
could be in two different target include directories and just sym linked
or whatever.)

Note that these files are (duplicated/shared) between glibc, libstdc++,
and libjava. At some point, that too should be cleaned up.

-benjamin