Bug#278379: Atomic stdc++ operations are broken on some MIPS machines

[Daniel Jacobowitz <dan@debian.org>]

On Wed, Oct 27, 2004 at 07:09:49PM +0200, Thiemo Seufer wrote:
> Daniel Jacobowitz wrote:
> [snip]
> > > The appended patch fixes it. It also changes the branch to the likely
> > > variant, this works around some breakage in early R10000 silicon.
> > > The patch is against gcc-3.3, newer gccs have the same problem, but
> > > have some apparently bogus changes in that area.
> > 
> > I don't know about the R10k workarounds, but newer GCC ought to have
> > the other problem fixed.  Is there something wrong with the version in
> > HEAD?
> 
> CVS HEAD fixes it but retains the odd ifdef around the .set mips2.
> The ifdef does no damage, but it it is also useless and misleading.
> The presence of ll/sc depends on the CPU class, not on the ABI.
> A plain MIPS I system without ll/sc emulation can't use this code
> anyway, and degrading the ISA level to MIPS II for those few
> instructions also doesn't matter.
> 
> The .set nomacro/.set noreorder stuff which includes the branch label
> should probably get forward-ported to HEAD as a safety measure.

Yes, sounds like a good idea.

> > IIRC, likely branches are deprecated in the latest MIPS ISAs; we
> > shouldn't be introducing more of them.  I don't know what silicon bug
> > you're working around, though, so I don't know if there's a better way.
> 
> R10000 before revision 2.6 fail to handle ll/sc atomically under
> somewhat obscure circumstances connected to the branch prediction
> mechanism and the pipeline length (Erratum #6). The branch likely
> avoids that specific bug. IRIX uses the same workaround, the Erratum
> suggests IIRC a much less efficient workaround.

Hmm.  I'm not sure what to do with this.  I don't want to add them to
libstdc++ since MIPS is threatening to remove them...

-- 
Daniel Jacobowitz