public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure
Date: Fri, 21 Jan 2022 16:16:52 +0000 [thread overview]
Message-ID: <bug-103121-4-XaPKTg43Zf@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103121-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #29 from Martin Sebor <msebor at gcc dot gnu.org> ---
>From memory: At use1 the cache is empty so go and find its definition and
record the offset at that point, with the pointer addition as the context. And
at use2 we look up the same offset. So use1 won't reflect the constant offset.
That could be both good (if the code is unreachable) and bad (if it is and the
use is invalid.
If it did work the way you're concerned I'd expect to see a lot of mysterious
false positives. The cache has been in use since GCC 11 and I don't recall
coming across any puzzling problems. But we have seen an uptick in false
positives in GCC 12 after we switched over to Ranger so let me double check it
really does work the way I say it does.
next prev parent reply other threads:[~2022-01-21 16:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-07 22:33 [Bug other/103121] New: Warnings danglin at gcc dot gnu.org
2021-11-08 8:19 ` [Bug other/103121] [12 Regression] Warnings in cp/optimize.c causing build failure pinskia at gcc dot gnu.org
2021-11-08 9:24 ` [Bug tree-optimization/103121] " rguenth at gcc dot gnu.org
2021-11-08 13:19 ` dave.anglin at bell dot net
2021-11-08 16:08 ` msebor at gcc dot gnu.org
2021-11-08 16:19 ` danglin at gcc dot gnu.org
2021-11-08 19:00 ` msebor at gcc dot gnu.org
2021-11-08 19:04 ` msebor at gcc dot gnu.org
2021-11-08 19:36 ` amacleod at redhat dot com
2021-11-08 19:50 ` msebor at gcc dot gnu.org
2021-11-08 20:07 ` amacleod at redhat dot com
2021-11-08 20:48 ` msebor at gcc dot gnu.org
2021-11-08 21:11 ` amacleod at redhat dot com
2021-11-08 21:48 ` msebor at gcc dot gnu.org
2021-11-08 22:35 ` msebor at gcc dot gnu.org
2021-11-09 0:01 ` amacleod at redhat dot com
2021-11-09 1:11 ` msebor at gcc dot gnu.org
2021-11-09 7:20 ` aldyh at gcc dot gnu.org
2021-11-09 7:24 ` aldyh at gcc dot gnu.org
2021-11-09 8:22 ` rguenth at gcc dot gnu.org
2022-01-18 14:34 ` rguenth at gcc dot gnu.org
2022-01-18 20:18 ` amacleod at redhat dot com
2022-01-19 7:36 ` rguenther at suse dot de
2022-01-19 17:50 ` amacleod at redhat dot com
2022-01-20 7:22 ` rguenther at suse dot de
2022-01-20 7:25 ` rguenth at gcc dot gnu.org
2022-01-20 15:49 ` amacleod at redhat dot com
2022-01-20 16:14 ` msebor at gcc dot gnu.org
2022-01-20 17:14 ` danglin at gcc dot gnu.org
2022-01-21 7:27 ` rguenther at suse dot de
2022-01-21 16:16 ` msebor at gcc dot gnu.org [this message]
2022-01-21 17:53 ` amacleod at redhat dot com
2022-01-21 18:59 ` msebor 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-103121-4-XaPKTg43Zf@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).