From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1392D3858432; Mon, 26 Feb 2024 09:58:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1392D3858432 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708941515; bh=Fh+g77aWQHCgiZCU4eaZvVybKrydGnELmi6uJBnktag=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n+RYWaxQVR1XSgHgSocXQ0x15zvl3o23S2qo9lYa7gazWOy3+e/7ICBC+mskKXxx+ y3PEh0IarGOKtUn4SnZbX4knpUeU1++DMWd5tly+I/c3Vfij/+9xUPewPrStsVxAZi DtQbBekd+t7nwqUEFuqZtX7GREnCh/QKRpcW2U7c= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100799] Stackoverflow in optimized code on PPC Date: Mon, 26 Feb 2024 09:58:25 +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 #28 from Jakub Jelinek --- (In reply to Peter Bergner from comment #27) > 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 t= he > number of parameters the C caller thinks there are (8 args, so no param s= ave > area needed) versus what the Fortran callee thinks there are (9 params wh= ich > 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 abo= ve, > in fact the character argument is never used either. What I see in the r= tl > dumps is that *all* incoming args have a REG_EQUIV generated that points = to > the param save area (this doesn't happen when there are 8 or fewer formal > params), even for the first 8 args that are passed in registers: Yes, so it is the backend that told function.cc that there is a parameter s= ave area and it should be adding REG_EQUIV notes. So, the idea would be that f= or 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. > > 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 = code > > with hidden Fortran character arguments. > As a HUGE hammer, every caller could always allocate a param save area.=20 > That would "fix" the problem from this bug, but would that also fix the b= ug > you're seeing in flexiblas? Most likely yes. Though of course that is way too high price to pay, even = with some non-default option. If we can't workaround it in the backend just on = the callee side of calls which have the unused hidden string length arguments, = then better no changes on the GCC side.=