From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4B3B43858422; Sun, 24 Dec 2023 09:14:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B3B43858422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1703409260; bh=aRtoamqInA239ew+rVb2pURRQiv/Z+xk7rEQM+Fc1sw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aUKYGesiX6/iKF2A788vrmOrRI9i8s4Ti5ooGS4mRbQBbEmSCDeyrIDJfQ1zWHS0G +oLTC6kUVf18WwGPxINqAMf3kTOEeSAYCfGCJGDbw3OyuJTHa5HCpNTIFfCYp0OeWv JUHDuaDvqHHLTiJAjichsSnvcX9jtnJR5ezRO9ow= From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113109] [14 Regression] g++ EH tests fail at execution time for cris-elf after r14-6674-g4759383245ac97 Date: Sun, 24 Dec 2023 09:13:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: EH, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.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=3D113109 --- Comment #14 from Hans-Peter Nilsson --- (In reply to GCC Commits from comment #9) > The master branch has been updated by Hans-Peter Nilsson : >=20 > https://gcc.gnu.org/g:3d03630b123411340e52d05124cb0cacfa1fc8b0 >=20 > commit r14-6817-g3d03630b123411340e52d05124cb0cacfa1fc8b0 > Author: Hans-Peter Nilsson > Date: Sun Dec 24 00:10:32 2023 +0100 >=20=20=20=20 > I haven't looked into why this problem, that appeared for the PA > already in 2007, was seen for CRIS only recently (with > r14-6674-g4759383245ac97). I should've removed that paragraph before committing. It's obvious from looking at r14-6674-g4759383245ac97 and the history of the expression in th= at context, and knowing that pa uses hard_frame_pointer_rtx... Still, why not all those other targets? (In reply to Jiu Fu Guo from comment #13) > (In reply to GCC Commits from comment #9) > > Conceptually, it's logical that stores to incoming args are > > optimized out on the return path or if no loads are seen - > > at least before epilogue expansion, when the subsequent load > > isn't seen in the RTL, as is the case for the "dse1" pass. >=20 > The stores to the argp/frame can be eliminated only if they are not used. > While for this case, the store may be used by EH handler, it should not be > optimized out.=20 That use is not seen before the pro/epilogue expansion pass. Maybe the pass should be restricted in what it does prior to that (not do in dse1, do in=20 dse2). > Thanks for catching and handling this quickly. >=20 > Happy holidays. No worries, same to you!=