public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-100799-4-Z3RthJarhJ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-100799-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 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
> 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 save
area and it should be adding REG_EQUIV notes.  So, the idea would be that for
the case we talk about (<= 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 <= 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. 
> That would "fix" the problem from this bug, but would that also fix the bug
> 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.

  parent reply	other threads:[~2024-02-26  9:58 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 11:20 [Bug fortran/100799] New: " alexander.grund@tu-dresden.de
2021-05-28 16:42 ` [Bug target/100799] " alexander.grund@tu-dresden.de
2021-06-01 19:08 ` bergner at gcc dot gnu.org
2021-06-01 21:09 ` segher at gcc dot gnu.org
2021-06-02  0:31 ` amodra at gmail dot com
2021-10-05 22:45 ` bergner at gcc dot gnu.org
2022-01-09 11:13 ` kenneth.hoste at ugent dot be
2022-07-08 10:53 ` alexander.grund@tu-dresden.de
2022-07-08 16:38 ` bergner at gcc dot gnu.org
2022-07-14 20:10 ` bergner at gcc dot gnu.org
2022-07-20 11:45 ` alexander.grund@tu-dresden.de
2022-07-20 14:14 ` alexander.grund@tu-dresden.de
2022-07-20 17:42 ` segher at gcc dot gnu.org
2022-07-20 17:59 ` segher at gcc dot gnu.org
2022-09-13 19:29 ` segher at gcc dot gnu.org
2022-09-19  5:46 ` jskumari at gcc dot gnu.org
2022-09-20 22:45 ` segher at gcc dot gnu.org
2022-10-17  8:17 ` jskumari at gcc dot gnu.org
2022-10-17  9:42 ` jskumari at gcc dot gnu.org
2022-10-17 17:10 ` jskumari at gcc dot gnu.org
2022-10-31  3:00 ` linkw at gcc dot gnu.org
2022-11-09 16:43 ` jskumari at gcc dot gnu.org
2023-06-19 20:25 ` bergner at gcc dot gnu.org
2024-02-21  7:38 ` jakub at gcc dot gnu.org
2024-02-22  2:51 ` bergner at gcc dot gnu.org
2024-02-22 14:44 ` bergner at gcc dot gnu.org
2024-02-22 14:59 ` jakub at gcc dot gnu.org
2024-02-25  0:39 ` bergner at gcc dot gnu.org
2024-02-26  9:58 ` jakub at gcc dot gnu.org [this message]
2024-02-27  0:45 ` bergner at gcc dot gnu.org
2024-02-27  7:26 ` jakub at gcc dot gnu.org
2024-02-27 15:30 ` bergner at gcc dot gnu.org
2024-03-01 15:25 ` bergner at gcc dot gnu.org
2024-03-22  7:44 ` aagarwa at gcc dot gnu.org
2024-03-22  7:45 ` aagarwa at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-100799-4-Z3RthJarhJ@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).