public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4
Date: Mon, 28 Aug 2023 12:12:04 +0000	[thread overview]
Message-ID: <bug-111157-4-RLvwAhtkTy@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111157-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> I think if IPA modref declares the argument dead at the call site then IPA
> CP/SRA cannot declare it known constant.

It is declared "killed" by the function.  I still need to figure out
whether that is all I need or whether the fact that it is not read
either is the combination I am after.  But I agree that IPA-CP should
refrain from propagating clearly unneeded info in that case.

> 
> Now, I wonder why IPA CP/SRA does not replace the known constant parameter
> with an automatic var like
> 
> point.constprop.isra (double ISRA.1740, int & restrict ipoint, double &
> restrict x, double & restrict y, double & restrict z, int & restrict istat)
> {
> ...
>   const int istat.local = 0;
>   istat = &istat.local;
> 
> ?  So if not all uses of 'istat' get resolved we avoid generating wrong
> code.  The expense is a constant pool entry (if not all uses are removed),
> but I think that's OK.  It would also work for aggregates.  It would also
> relieve IPA-CP modification phase from doing anything but trival value
> replacement (in case the arg isn't apointer).

I'm afraid I don't understand.  Even in this particular case, istat is
checked by the caller and the callee can assign to it also other
values, not just the one which happens to be what it it initialized to
by the caller - and in the original code it does when there is an
error - those writes cannot be redirected to a local variable.

  parent reply	other threads:[~2023-08-28 12:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25 14:30 [Bug ipa/111157] New: " jamborm at gcc dot gnu.org
2023-08-25 15:57 ` [Bug ipa/111157] [14 Regression] " pinskia at gcc dot gnu.org
2023-08-25 16:46 ` jamborm at gcc dot gnu.org
2023-08-25 17:14 ` jamborm at gcc dot gnu.org
2023-08-25 20:07 ` jamborm at gcc dot gnu.org
2023-08-26 11:50 ` hubicka at gcc dot gnu.org
2023-08-28  7:18 ` rguenth at gcc dot gnu.org
2023-08-28 12:12 ` jamborm at gcc dot gnu.org [this message]
2023-08-28 12:16 ` jamborm at gcc dot gnu.org
2023-08-29 11:32 ` hubicka at ucw dot cz
2023-10-05 12:22 ` jamborm at gcc dot gnu.org
2023-10-17 12:28 ` rguenth at gcc dot gnu.org
2023-10-30 17:38 ` cvs-commit at gcc dot gnu.org
2023-10-30 17:38 ` cvs-commit at gcc dot gnu.org
2023-10-30 17:41 ` jamborm at gcc dot gnu.org
2023-10-31  7:43 ` rguenth 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-111157-4-RLvwAhtkTy@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).