From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8A2D93871020; Sat, 1 Jun 2024 03:35:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A2D93871020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717212909; bh=qxa7J907YDVklt8d1hxuxP9pEJn3tdPYo/JCGXz6ImU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ppnAMwdZrltomL+PjtYT2wmP1jFEt5DvpvZeSWq4xThzyfplhNBVB0hB+ltyCXCkm XdWoU2ghhaOODxgzGoyHsaRty84zu8sXzs9weZjH5+sGagQLvOz7Mezhj4tRGTaSWv Pzcr95H1OwoZSrQ5VKxfhlg4a2zhyEIJFHufbgH4= From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC Date: Sat, 01 Jun 2024 03:35:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 15.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hp at gcc dot gnu.org X-Bugzilla-Target-Milestone: 15.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115284 --- Comment #12 from Hans-Peter Nilsson --- (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #11) > > --- Comment #10 from Hans-Peter Nilsson --- > >> 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 sp= arc by > > means of using the binfmt machinery that Jeff mentioned in the thread w= here I > > mentioned the revert on gcc-patches, would work. (I don't have the det= ails and > > don't remember if I'd actually tried it, certainly not recently; I just= know > > about the concept.) >=20 > 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 >=20 > https://wiki.qemu.org/Documentation/Platforms/SPARC >=20 > 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-histor= ic 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 ident= ical 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 failur= e 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 prob= lem > > manifests there. > I've tried that now on both >=20 > * 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-linu= x.=20 On the other hand, an existing reproducer is so much easier to handle. Tha= nk you and thanks in advance for the last step!=