public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "w at 1wt dot eu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/98503] [11/12 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
Date: Wed, 23 Mar 2022 09:32:39 +0000	[thread overview]
Message-ID: <bug-98503-4-IEoYzXDZRu@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-98503-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #19 from Willy Tarreau <w at 1wt dot eu> ---
Hello Richard,

Thanks for looking at this old issue.

> that means next_step will do the bad access of 'head' using the struct ref
> type.

Actually there's no bad access, as if you look closely, next_step() restarts
from cur->list.n, hence undoes exactly what initial_step() did.

In addition for the special case here, the list happens to be at the beginning
of the struct so there's not even an offset of difference between the list head
and the member, so get_initial_step() really returns head here, and next_step()
will return exactly head as well, which does match the stop condition in the
following while() block and never causes any dereference of any unmapped area.

I noticed I have left a mistake when writing the simplified reproducer, I
didn't initialise head, thus I thought it could have contributed to the warning
in the reproducer, but retesting with:

    static struct list head = { .n = &head, .p = &head };

doesn't change anything.

Since then we've worked around this problem by using some ugly casts because
removing the warning could have more long-term consequences if it occasionally
allows to trigger on a real issue. Still I find it sad when a warning forces us
to introduce dangerous casts as a workaround.

      parent reply	other threads:[~2022-03-23  9:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-03  7:53 [Bug c/98503] New: [11 regression] -Warray-bounds false positive with global variables at -O2 w at 1wt dot eu
2021-01-03  7:56 ` [Bug c/98503] " w at 1wt dot eu
2021-01-04 12:33 ` [Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da marxin at gcc dot gnu.org
2021-01-04 16:06 ` msebor at gcc dot gnu.org
2021-01-04 16:17 ` w at 1wt dot eu
2021-01-04 16:19 ` w at 1wt dot eu
2021-01-04 17:41 ` msebor at gcc dot gnu.org
2021-01-04 22:43 ` w at 1wt dot eu
2021-01-05 11:16 ` rguenth at gcc dot gnu.org
2021-01-05 11:34 ` w at 1wt dot eu
2021-01-05 17:31 ` msebor at gcc dot gnu.org
2021-01-28 23:06 ` [Bug middle-end/98503] " msebor at gcc dot gnu.org
2021-04-27 11:40 ` [Bug middle-end/98503] [11/12 " jakub at gcc dot gnu.org
2021-05-05 16:52 ` msebor at gcc dot gnu.org
2021-05-05 17:16 ` w at 1wt dot eu
2021-07-28  7:05 ` rguenth at gcc dot gnu.org
2021-11-17 22:34 ` msebor at gcc dot gnu.org
2022-03-08  0:03 ` msebor at gcc dot gnu.org
2022-03-23  8:31 ` rguenth at gcc dot gnu.org
2022-03-23  9:32 ` w at 1wt dot eu [this message]

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-98503-4-IEoYzXDZRu@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).