https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #10 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > > Uni-Bielefeld.DE> --- > >> --- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- > [...] > >> versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as > >> well. > > > > I happen to have a Linux/sparc64 LDom around: I'll give it a whirl. > > The failure is even earlier here: in a sparc64-unknown-linux-gnu > bootstrap, building a libstdc++ .gch file in stage 2 breaks: Great, thanks! That means that tricking my pc into believing it's a sparc by means of using the binfmt machinery that Jeff mentioned in the thread where I mentioned the revert on gcc-patches, would work. (I don't have the details and don't remember if I'd actually tried it, certainly not recently; I just know about the concept.) What's not so great is that the described reproducer is a bootstrap, so the debug situation is unpleasant. The first step I'd do, would be to just do a cross-build (or native --disable-bootstrap) and just run the testsuite before/after the patch-set (or just 933ab59c59bdc1) and see if the problem manifests there. It's also not great (from the view of gcc targeting architectures with delay-slots) that this isn't at the top of my queue anymore, since the immediate situation was resolved; as mentioned I committed the revert. I'll get to it eventually, but if someone is intrigued enough by the prospect of a 0.36%-ish performance improvement (see commit log for the culprit commit) to do such a --disable-bootstrap regtest, that'd help. :) Thank you for your patience and for the help.
