From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C62993857705; Thu, 22 Feb 2024 14:59:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C62993857705 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708613987; bh=wFALh4F0WbJ2XFlbABPptJC61GlQbsVhRHYtXET31oU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q+yxA/UZnHLf0XfKjBlfBTtb4zj8iNTzWBYlqqlmy4nQQi3XSn9AToO4dF0A9U9H0 gVh2YSvJ5rVmRhRVIESVJsdL1A0thHb/f1Rt/2bm0ZuUs5zaHgcW0XRX5y/GTzSvwW ZXq4IV/2boQBEDOWlNOckBdqx2M/nKYy+a8vI8LQ= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100799] Stackoverflow in optimized code on PPC Date: Thu, 22 Feb 2024 14:59: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: jakub 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 #26 from Jakub Jelinek --- (In reply to Peter Bergner from comment #25) > CCing Mike and David for possible comments about the possible workarounds > mentioned in Comment 23 and Comment 24. Doing the workaround on the caller side is impossible, this is for calls fr= om C/C++ to Fortran code, directly or indirectly called and there is nothing t= he compiler could use to guess that it actually calls Fortran code with hidden Fortran character arguments. 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 (ok, sure, it could just load from the assumed parameter location and don't assu= me the rest is there, nor allow storing to the slots it loaded them from). But that is actually not what BLAS etc. suffers from. If you have something like subroutine foo (a, b, c, d, e, f, g, h) character a integer b, c, d, e, f, g, h call bar (a, b, c, d, e, f, g, h) end subroutine foo then the DECL_HIDDEN_STRING_LENGTH argument isn't used at all, on the callee side the user said that one should treat it as if the length of a is 1, so whatever the caller passes is unimportant and when passing to further calls= it will just use 1: void foo (character(kind=3D1)[1:1] & restrict a, integer(kind=3D4) & restri= ct b, integer(kind=3D4) & restrict c, integer(kind=3D4) & restrict d, integer(kin= d=3D4) & restrict e, integer(kind=3D4) & restrict f, integer(kind=3D4) & restrict g, integer(kind=3D4) & restrict h, integer(kind=3D8) _a) { : bar (a_2(D), b_3(D), c_4(D), d_5(D), e_6(D), f_7(D), g_8(D), h_9(D), 1); return; } It would seem that the _a argument is useless, but as explained in PR90329 = that is because in Fortran you can call foo ("foo", 1, 2, 3, 4, 5, 6, 7) without interfaces etc. and the first argument could be character, character(len=3D1), character(le= n=3D3) or character(len=3D*) etc. And only in the last case the argument is actua= lly needed, in other cases it is ignored. So, the workaround could be for the case of unused DECL_HIDDEN_STRING_LENGTH 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_LENGT= H or used DECL_HIDDEN_STRING_LENGTH arguments actually require it.=