From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4F467385841B; Sun, 25 Feb 2024 00:39:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4F467385841B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708821569; bh=xK+AQjCLEQcPjfNCWPeoH8tF50Fot9OvwME5eScZVgM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JocQwYST1iQgqsGOaGTIQT0CG6vm4COsphontTN3LvbJW1kOnbJw1aC19/I9+u6w8 xnENga8p6r2+93lD/P2kz/foKtdQBQ1EdS/Qtr6P2SUZmGl7EpDlr/Gx4a178XWPus XlocrRM+0QbDr4MFp/fHjcfOJWEB9umj02FuBLEs= From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100799] Stackoverflow in optimized code on PPC Date: Sun, 25 Feb 2024 00:39:23 +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 #27 from Peter Bergner --- (In reply to Jakub Jelinek from comment #26) > But I still think the workaround is possible on the callee side. > Sure, if the DECL_HIDDEN_STRING_LENGTH argument(s) is(are) used in the > function, then there is no easy way but expect the parameter save area (o= k, > sure, it could just load from the assumed parameter location and don't > assume the rest is there, nor allow storing to the slots it loaded them > from). > But that is actually not what BLAS etc. suffers from. [snip] > So, the workaround could be for the case of unused DECL_HIDDEN_STRING_LEN= GTH > arguments at the end of PARM_DECLs don't try to load those at all and don= 't > assume there is parameter save area unless the non-DECL_HIDDEN_STRING_LEN= GTH > or used DECL_HIDDEN_STRING_LENGTH arguments actually require it. So I looked closer at what the failure mode was in this PR (versus the one you're seeing with flexiblas). As in your case, there is a mismatch in the number of parameters the C caller thinks there are (8 args, so no param save area needed) versus what the Fortran callee thinks there are (9 params which include the one hidden arg, so there is a param save area). The Fortran function doesn't actually access the hidden argument in our test case above= , in fact the character argument is never used either. What I see in the rtl du= mps is that *all* incoming args have a REG_EQUIV generated that points to the p= aram save area (this doesn't happen when there are 8 or fewer formal params), ev= en for the first 8 args that are passed in registers: (insn 2 12 3 2 (set (reg/v/f:DI 117 [ r3 ]) (reg:DI 3 3 [ r3 ])) "callee-3.c":6:1 685 {*movdi_internal64} (expr_list:REG_EQUIV (mem/f/c:DI (plus:DI (reg/f:DI 99 ap) (const_int 32 [0x20])) [1 r3+0 S8 A64]) (nil))) (insn 3 2 4 2 (set (reg/v:DI 118 [ r4 ]) (reg:DI 4 4 [ r4 ])) "callee-3.c":6:1 685 {*movdi_internal64} (expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 99 ap) (const_int 40 [0x28])) [2 r4+0 S8 A64]) (nil))) ... We then get to RA and we end up spilling one of the pseudos associated with= one of the other parameters (not the character param JOB). LRA then uses that REG_EQUIV note and rather than allocating a new stack slot to spill to, it = uses the parameter save memory location for that parameter for the spill slot. = When we store to that memory location and the C caller has not allocated the par= am save area, we end up clobbering an important part of the C callers stack causing a crash. If we were to try and do a callee workaround, we would need to disable sett= ing those REG_EQUIV notes for the parameters... if that's even possible. Since Fortran uses call-by-name parameter passing, isn't the updated param value = from the callee returned in the parameter save area itself??? > Doing the workaround on the caller side is impossible, this is for calls > from C/C++ to Fortran code, directly or indirectly called and there is > nothing the compiler could use to guess that it actually calls Fortran co= de > with hidden Fortran character arguments. As a HUGE hammer, every caller could always allocate a param save area. Th= at would "fix" the problem from this bug, but would that also fix the bug you'= re seeing in flexiblas? I'm not advocating this though. I was thinking maybe making callers (under= an option?) conservatively assume the callee is a Fortran function and for tho= se C arguments that could map to a Fortran parameter with a hidden argument, bump the number of counted args by 1. For example, a C function with 2 char/cha= r * args and 6 int args would think there are 8 normal args and 2 hidden args, = so it needs to allocate a param save area. Is that not feasible? ...or does = that not even address the issue you're seeing in your bug?=