From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 588D93858C66; Mon, 12 Feb 2024 17:25:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 588D93858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707758745; bh=ATflmrbG1FZB7I4trxgjSE0vNldWkcWd0kXY13SIT/U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jqpBiv2QsWmqRe6x82cRdtAzC+hqPaWdJoZR7YYGh5ayfCMge56XGgI7dVlG18671 q5JrKLZOLf9FsjxVtryzRebqcJQOi+21Phj8YkQGcnRUQEmdbz1hp0waXRmfixM2lW FgsgHI+oOVburJ+XLis2cQ8/juiLXdGHPxPkUM8o= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9) since r10-3311-gff6686d2e5f797 Date: Mon, 12 Feb 2024 17:25:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113712 --- Comment #19 from Andrew Pinski --- (In reply to Martin Jambor from comment #18) > (In reply to Filip Kastl from comment #17) > > I've bisected this (using the test from Andrew Pinski) to > > r10-3311-gff6686d2e5f797 >=20 > That's a coincidence, with -fno-ipa-sra the testcase fails even earlier, > IPA-SRA was just hiding it, most probably by localizing some symbol before > the linking stage. >=20 > Bugs that are only reproducible with -fno-use-linker-plugin are unlikely = to > get a high priority. But I understand that the original issue does not n= eed > it? I am not 100% sure if the original reported issue had been using the LTO pl= ugin because I could not reproduce it when using the plugin.=20 >=20 > (Also, the issue is supposed to be reproducible ton x86_64-linux, right?) Yes it is supposed to be reproducible on x86_64; I reduced it there.=