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

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

[ro at gcc dot gnu.org]

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

            Bug ID: 115284
           Summary: [15 regression] SEGV in check_format_arg on
                    Solaris/SPARC
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: hp at gcc dot gnu.org
  Target Milestone: ---
              Host: sparc*-sun-solaris2.11
            Target: sparc*-sun-solaris2.11
             Build: sparc*-sun-solaris2.11

Between 20240528 (c08b0d3f7b3539b26031de31d88dea6b94474577) and 20240529
(18f477980c8597fe3dca2c2e8bd533c0c2b17aa6),
Solaris/SPARC bootstrap (both 32 and 64-bit-default) got broken.  In stage 3,
cc1plus SEGVs:

/vol/gcc/src/hg/master/local/gcc/analyzer/supergraph.cc: In member function
'virtual void ana::superedge::dump_dot(graphviz_out*, const
dedge<ana::supergraph_traits>::dump_args_t&) const':
/vol/gcc/src/hg/master/local/gcc/analyzer/supergraph.cc:971:13: internal
compiler error: Segmentation Fault
  971 |   pp_printf (pp,
      |   ~~~~~~~~~~^~~~
  972 |              (" [style=%s, color=%s, weight=%d, constraint=%s,"
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  973 |               " ltail=\"cluster_node_%i\", lhead=\"cluster_node_%i\""
      |               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  974 |               " headlabel=\""),
      |               ~~~~~~~~~~~~~~~~~
  975 |              style, color, weight, constraint,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  976 |              m_src->m_index, m_dest->m_index);
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This reproduces easily with

c1plus -fpreprocessed supergraph.ii -quiet -mcpu=v9 -Wall -o supergraph.s

gdb shows

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00c7dd4c in check_format_arg(void*, tree_node*, unsigned long long) ()
(gdb) bt
#0  0x00c7dd4c in check_format_arg(void*, tree_node*, unsigned long long) ()
#1  0x00c5e270 in check_function_arguments_recurse(void (*)(void*, tree_node*,
unsigned long long), void*, tree_node*, unsigned long long, opt_code) ()
#2  0x00c76b00 in check_function_format(tree_node const*, tree_node*, int,
tree_node**, vec<unsigned int, va_heap, vl_ptr>*) ()
#3  0x00c5e884 in check_function_arguments(unsigned int, tree_node const*,
tree_node const*, int, tree_node**, vec<unsigned int, va_heap, vl_ptr>*) ()
#4  0x0082bff4 in build_over_call(z_candidate*, int, int) ()
#5  0x0082e9d4 in build_new_function_call(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int) ()
#6  0x00b85f98 in finish_call_expr(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, bool, bool, int) ()
#7  0x00a93e1c in cp_parser_postfix_expression(cp_parser*, bool, bool, bool,
bool, cp_id_kind*) ()
#8  0x00a9b230 in cp_parser_unary_expression(cp_parser*, cp_id_kind*, bool,
bool, bool) ()
#9  0x00a64518 in cp_parser_cast_expression(cp_parser*, bool, bool, bool,
cp_id_kind*) ()
#10 0x00a65600 in cp_parser_binary_expression(cp_parser*, bool, bool, bool,
cp_parser_prec, cp_id_kind*) ()
#11 0x00a6666c in cp_parser_assignment_expression(cp_parser*, cp_id_kind*,
bool, bool) ()
#12 0x00a66c8c in cp_parser_expression(cp_parser*, cp_id_kind*, bool, bool,
bool) ()
#13 0x00a6efa0 in cp_parser_expression_statement(cp_parser*, tree_node*) ()
#14 0x00ab5e10 in cp_parser_statement(cp_parser*, tree_node*, bool, bool*,
vec<tree_node*, va_heap, vl_ptr>*, unsigned int*) ()
#15 0x00a7f5e0 in cp_parser_statement_seq_opt(cp_parser*, tree_node*) ()
#16 0x00a7f8e0 in cp_parser_compound_statement(cp_parser*, tree_node*, int,
bool) ()
#17 0x00aab70c in cp_parser_ctor_initializer_opt_and_function_body(cp_parser*,
bool) ()
#18 0x00ab2960 in cp_parser_function_definition_after_declarator(cp_parser*,
bool) ()
#19 0x00ab3ebc in cp_parser_init_declarator(cp_parser*, int,
cp_decl_specifier_seq*, vec<deferred_access_check, va_gc, vl_embed>*, bool,
bool, int, bool*, tree_node**, unsigned int*, tree_node**) ()
#20 0x00a7b638 in cp_parser_simple_declaration(cp_parser*, bool, tree_node**)
    ()
#21 0x00ac42bc in cp_parser_declaration(cp_parser*, tree_node*) ()
#22 0x00ac29bc in cp_parser_declaration_seq_opt(cp_parser*) ()
#23 0x00ac3000 in cp_parser_namespace_definition(cp_parser*) ()
#24 0x00ac4ad0 in cp_parser_declaration(cp_parser*, tree_node*) ()
#25 0x00ac5550 in c_parse_file() ()
#26 0x00c9f15c in c_common_parse_file() ()
#27 0x013d858c in compile_file() ()
#28 0x013dc25c in toplev::main(int, char**) ()
#29 0x02284358 in main ()

A reghunt identified this patch

commit 933ab59c59bdc1ac9e3ca3a56527836564e1821b
Author: Hans-Peter Nilsson <hp@axis.com>
Date:   Tue May 28 23:16:48 2024 +0200

    resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN

as the culprit.

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.0

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

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |hp at gcc dot gnu.org
   Last reconfirmed|                            |2024-05-29

--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Sorry.  I bet something in reorg actually uses a barrier insn as a reference.
I'll revert those three patches unless I can fix the problem within 24 hours
(not counting regtest-time).

Incidentally, can you please post a configure line for cfarm210 or cfarm211
that works?  (A no-options line failed to find some library during bootstrap so
I originally bailed on sparc testing.)

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
> Sorry.  I bet something in reorg actually uses a barrier insn as a reference.
> I'll revert those three patches unless I can fix the problem within 24 hours
> (not counting regtest-time).

Ok.  For this night's bootstrap, I'm using the tree at the revision
before the culprit patch.  I tried to revert just that one, but failed
(conflicts and manual resolution failed compiling stage 1 libgcc).

> Incidentally, can you please post a configure line for cfarm210 or cfarm211
> that works?  (A no-options line failed to find some library during bootstrap so
> I originally bailed on sparc testing.)

You should use cfarm216 instead: it's way faster than the others and
runs Solaris 11.4, which is the only OS release supported on trunk.

Aldy, when investigating PR ipa/114985, got along with just

configure && make -j128 && make check -j128 -k

While that has its downsides, for the purposes of this investigation it
should do the trick.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
[...]
> Aldy, when investigating PR ipa/114985, got along with just
>
> configure && make -j128 && make check -j128 -k
>
> While that has its downsides, for the purposes of this investigation it
> should do the trick.

Oh, I forgot: you can speed up the build quite a bit by disabling
unnecessary languages, multilibs, and runtime libs.  Here's what I used
for the reghunt:

configure --enable-languages=c,c++ --disable-lto --disable-libatomic
--disable-libcc1 --disable-libquadmath --disable-libssp --disable-libitm
--disable-libvtv --disable-libsanitizer --disable-libgomp --disable-multilib

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

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)

> You should use cfarm216 instead: it's way faster than the others and
> runs Solaris 11.4, which is the only OS release supported on trunk.
I can't reach cfarm216, something with my ssh setup is too old. :(

Also, I just realized it can't be a plain NULL basic_block, because that'd have
shown a SEGV in resource.c.  All the more interest in a way to reproduce on
cfarm210 or cfarm211.

> > --- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
> > Sorry.  I bet something in reorg actually uses a barrier insn as a reference.
> > I'll revert those three patches unless I can fix the problem within 24 hours
> > (not counting regtest-time).
> 
> Ok.  For this night's bootstrap, I'm using the tree at the revision
> before the culprit patch.  I tried to revert just that one, but failed
> (conflicts and manual resolution failed compiling stage 1 libgcc).
There's two other commits after the culprit, that depends on it functionally
and contextually, so you have to revert those too.

Either way, if you prefer to revert (the failing one and the two after that one
obviously in opposite order, I'd be thankful.  I'll likely land there myself as
I currently have no way to reproduce the problem.

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

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
The bootstrap issue should be resolved with r15-916, which can't appear here
because the commit log of a revert must not be edited.

Please don't close this PR, the revert is just a band-aid.

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

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
BTW, I see the target list says sparc*-sun-solaris2.11 which seems a cutnpasto
from some ancient template: that particular version is installed on cfarm211
and a build log for a recent gcc checkout says "Configuration
sparc-sun-solaris2.11 not supported" for the gcc dir.  (Please correct the
versions.)  BTW, it'd be nice to know it it reproduces for sparc-linux as well.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
>
>> You should use cfarm216 instead: it's way faster than the others and
>> runs Solaris 11.4, which is the only OS release supported on trunk.
> I can't reach cfarm216, something with my ssh setup is too old. :(

Strange: you're the first to report such an issue, and there are quite a
number of users of the system.

> Also, I just realized it can't be a plain NULL basic_block, because that'd have
> shown a SEGV in resource.c.  All the more interest in a way to reproduce on
> cfarm210 or cfarm211.

There's no point in trying: trunk isn't supported on either Solaris 10
(cfarm210) or Solaris 11.3 (cfarm211).

>> Ok.  For this night's bootstrap, I'm using the tree at the revision
>> before the culprit patch.  I tried to revert just that one, but failed
>> (conflicts and manual resolution failed compiling stage 1 libgcc).
> There's two other commits after the culprit, that depends on it functionally
> and contextually, so you have to revert those too.

I suspected that much, but was in a bit of hurry to get the bootstraps
going before I went to bed.

> Either way, if you prefer to revert (the failing one and the two after that one
> obviously in opposite order, I'd be thankful.  I'll likely land there myself as
> I currently have no way to reproduce the problem.

I've no problem with just reverting locally for a day or two.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- 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> ---
> BTW, I see the target list says sparc*-sun-solaris2.11 which seems a cutnpasto
> from some ancient template: that particular version is installed on cfarm211

It's not: I've tried bootstraps on sparc-sun-solaris2.11 and
sparcv9-sun-solaris2.11 to check if it's just a 32-bit issue.

> and a build log for a recent gcc checkout says "Configuration
> sparc-sun-solaris2.11 not supported" for the gcc dir.  (Please correct the

While the configure triples have no way to distinguish between Solaris
11.3 and 11.4, gcc/config.gcc explicitly checks for hosts running 11.4.

But I see what you mean: that's an error of mine moving 11.3 from
obsolete to unsupported.  The message should say

        sparc-sun-solaris2.11.3 not supported

instead.  Will fix.

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

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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:

n file included from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:60,
                 from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:64,
                 from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/algorithm:60,
                 from
/vol/gcc/src/hg/master/solaris/libstdc++-v3/include/precompiled/stdc++.h:51:
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::integral_constant<bool, true>':
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:296:72:
  required from here
  296 |    constexpr true_type __is_complete_or_unbounded(__type_identity<_Tp>)
      |                                                                       ^
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:92:17:
internal compiler error: tree check: expected tree that contains 'decl common'
structure, have 'function_decl' in tsubst_arg_types, at cp/pt.cc:15782
   92 |       constexpr operator value_type() const noexcept { return value; }
      |                 ^~~~~~~~
0xfff8000100a2f087 __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0xfff8000100a2f1a3 __libc_start_main_impl
        ./csu/libc-start.c:360

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

[hp at gcc dot gnu.org]

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

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.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

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

[hp at gcc dot gnu.org]

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

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

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

Thanks for the warning, but I'm confused as it doesn't look too bad to me; for
example the status field for SPARC64 says "working" at least for non-historic
qemu versions.  What am I missing?  Are you thinking of something specific
there?

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

Also, I wouldn't be using qemu-system-sparc64 IIUC: with the binfmt trick I'd
be using qemu-user.

That "experience" (assuming success) would also lead to a template or identical
solution for other targets, which is the most interesting part.  The cfarm is
nice to have, but the machines are a bit crowded.

> 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 ;-)

A different nightmare, leading to a nightmare of chasing a bootstrap failure on
a system I'm not familiar with (referring to solaris on the cfarm machine).

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

> 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

Oh, too bad.  Thanks for doing that!

> * 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.

Hm, the part where you compare results against a baseline is pretty central.

One the one hand, when it doesn't manifest for sparc64-solaris just through the
testsuite, the odds are against it manifesting that simple for sparc64-linux. 
On the other hand, an existing reproducer is so much easier to handle.  Thank
you and thanks in advance for the last step!

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #11)
[...]
>> * 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.
>
> Hm, the part where you compare results against a baseline is pretty central.
>
> One the one hand, when it doesn't manifest for sparc64-solaris just through the
> testsuite, the odds are against it manifesting that simple for sparc64-linux. 
> On the other hand, an existing reproducer is so much easier to handle.  Thank
> you and thanks in advance for the last step!

I've completed the sparc64-linux comparison now: no regressions with a
non-bootstrap build and your patches either, thus the same situation as
on Solaris.

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

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #13)
> I've completed the sparc64-linux comparison now: no regressions with a
> non-bootstrap build and your patches either, thus the same situation as
> on Solaris.

Thank you for doing this!

I was a bit worried you'd find something, so I'd lose the incentive to get a
sparc64 -or general- bootstrap environment working, one way or the other.
(j/k :)