[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
> (In reply to ro@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.)

I can't help but wonder if this wouldn't be a total waste of your time:
considering what the qemu wiki docments for SPARC support

https://wiki.qemu.org/Documentation/Platforms/SPARC

seems not too encouraging for 64-bit systems.  When I think about what
it took myself to get recent macOS working on qemu-kvm (although the
procedure is resonably well documented, with firmware and all
available), I'd consider such an attempt a positive nightmare.

When all it takes for you to either get your ssh client working to
access a ready-made and not too slow SPARC system (or in the worst case,
build OpenSSH from source), I know which route I'd take ;-)

> 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. :)

I've tried that now on both

* sparc-sun-solaris2.11 (c and c++ only): no additional testsuite
  failures are apparent there, which is not too astonishing given that
  the bootstrap failure occurs in stage 3, suggesting a mis-compiled
  stage 2 cc1plus, and

* sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite
  failures all over the place, but I'd have to perform another bootstrap
  with your patches removed to make an exact comparison.