From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Jeff Law <jeffreyalaw@gmail.com>,
segher@kernel.crashing.org
Subject: Re: [PATCH v2] combine: Fix ICE in try_combine on pr112494.c [PR112560]
Date: Thu, 7 Mar 2024 11:45:45 +0100 (CET) [thread overview]
Message-ID: <p26147s2-9017-8733-n456-19o50s1862o6@fhfr.qr> (raw)
In-Reply-To: <ZemY+q8FLQknQTT4@tucnak>
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > The following might also fix the issue and preserve more of the
> > > rest of the flow of the function.
> > >
> > > If that works I'd prefer it. But I'll defer approval to the combine
> > > maintainer which is Segher.
> >
> > Your patch is basically what v1 did [1], but it was suggested (in a
> > reply by you ;) ) that we should stop the attempt to combine if we
> > can't handle the use. So, the v2 patch undoes the combine and records
> > a nice message in this case.
>
> My understanding of Richi's patch is that it it treats the non-COMPARISON_P
> the same as if find_single_use fails, which is a common case that certainly
> has to be handled right and it doesn't seem that we are giving up completely
> for that case. So, I think it is reasonable to treat the non-COMPARISON_P
> *cc_use_loc as NULL cc_use_loc.
The question is, whether a NULL cc_use_loc (find_single_use returning
NULL) means "there is no use" or it can mean "huh, don't know, maybe
more than one, maybe I was too stupid to indentify the single use".
The implementation suggests it's all broken ;)
Richard.
next prev parent reply other threads:[~2024-03-07 11:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 9:16 Uros Bizjak
2024-03-07 9:55 ` Richard Biener
2024-03-07 10:11 ` Uros Bizjak
2024-03-07 10:22 ` Richard Biener
2024-03-07 17:44 ` Segher Boessenkool
2024-03-07 10:37 ` Jakub Jelinek
2024-03-07 10:45 ` Richard Biener [this message]
2024-03-07 11:22 ` Uros Bizjak
2024-03-07 17:51 ` Segher Boessenkool
2024-03-07 17:49 ` Segher Boessenkool
2024-03-07 10:57 ` Uros Bizjak
2024-03-07 17:36 ` Segher Boessenkool
2024-03-07 21:04 ` Uros Bizjak
2024-03-07 21:08 ` Uros Bizjak
2024-03-07 21:35 ` Segher Boessenkool
2024-03-07 22:07 ` Uros Bizjak
2024-03-07 22:27 ` Segher Boessenkool
2024-03-07 22:46 ` Uros Bizjak
2024-03-18 14:49 ` Segher Boessenkool
2024-03-18 15:44 ` Uros Bizjak
2024-03-07 22:27 ` Uros Bizjak
2024-03-18 14:44 ` Segher Boessenkool
2024-03-18 15:29 ` Uros Bizjak
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=p26147s2-9017-8733-n456-19o50s1862o6@fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=segher@kernel.crashing.org \
--cc=ubizjak@gmail.com \
/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).