From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6A4C73842422; Thu, 2 Jul 2020 15:30:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A4C73842422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1593703817; bh=SrCSq6i0EM2SSfvj0dV4+Hu0cRvQvj7Ouqm2dKDc+eg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BRx1u2zJt1P1hP4MDhXjP/6FRofe0GVQuYaQwkmmfF519Mv4E88hifutCTnhm2yg1 VxkuwGR/wCtFnd434lRUTaM0PAH0NgM4jbC6Fym0WzngrTXGaBgb9Y8bd0MoqWL+7Y wwxjqirguwX+DS1BIqPGqsFmPUFqtunMt1oC5Pyw= From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux Date: Thu, 02 Jul 2020 15:30:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 8.4.1 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: bergner at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.5 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 15:30:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95952 --- Comment #11 from Peter Bergner --- (In reply to Mikael Pettersson from comment #9) > binutils-2.23.88.0.1-13.fc20.ppc64 >=20 > I can build a recent binutils release and retry the gcc-8 bootstrap with > that tomorrow. But since gcc-9/10/11 all bootstrap Ok, I find it difficu= lt > to suspect it's a binutils issue. At some point in the past, GCC used to disable some instruction patterns depending on whether the binutils you're building against supports those instructions or not. Now, GCC will always generate every instruction you a= sk it to, but you might get an assembler error trying to assemble those instructions. I think that change was somewhere in the GCC8 or GCC9 timefr= ame. It could be your old binutils in GCC8 is silently turning off some support= and that is causing the problem. I'll try building a 2.23ish binutils and using that for my GCC8 build.=