From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 767943858C54; Tue, 27 Feb 2024 00:45:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 767943858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708994751; bh=bjTBllC9QTDt8jJINkK2jdxXeeiRcavLbllL/R1LLWU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZMW0ura/iuMcYVHiknQf8JIQMHR8BGwg9YIVxlqKogkkFESXclhdKpJFMuH0uom50 ZSDH/UNmuPCgE0jji+wjwWPx3V4n+vTvjI4+epVCf6o/MaZI1r3bZ1rw6mrWZoS7u5 qsHZO7OT7lZU7F1QnxbjTmz1Q3war7NVmLWE5mnE= From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100799] Stackoverflow in optimized code on PPC Date: Tue, 27 Feb 2024 00:45:47 +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: 10.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bergner at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jskumari at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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=3D100799 --- Comment #29 from Peter Bergner --- (In reply to Jakub Jelinek from comment #28) > Yes, so it is the backend that told function.cc that there is a parameter > save area and it should be adding REG_EQUIV notes. So, the idea would be > that for the case we talk about (<=3D 8 normal arguments, then only unused > DECL_HIDDEN_STRING_LENGTH ones) that the backend would also say that there > is no parameter save area, basically pretend there are <=3D 8 arguments. How can we know there are no uses of the hidden arg(s)? That backend funct= ion is being called at expand time, so we haven't yet run any RTL dataflow information to tell us. Is there some tree attribute for the arg that can = tell is whether it's used or not? ...or is there some SSA data for that arg that can show it has no use? ...and if so, would that still work for -O0 compil= es?=