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 c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da Date: Tue, 05 Jan 2021 11:34:45 +0000 [thread overview] Message-ID: <bug-98503-4-diXqgfUozm@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 #9 from Willy Tarreau <w at 1wt dot eu> --- Hi Richard, indeed, the &curr->list == &head is the test for end of list that prevents any bad access from happening. I know that usually the right way to do this is by using a list element, but sometimes it requires placing casts all over the code, or container_of() and friends in every single call, which is way more error-prone. Writing state machines with different input types in general doesn't result in reliable long-term code. It turns out that in the code affected by this there were only two call places that I could tear a little bit to use the list instead (and an alias pointer, which I hate keeping) but I'm not extremely happy with this workaround. I'm well aware that there can be aliasing issues while doing this, which is also why I tested with -fno-strict-aliasing and saw the warninig remain, which I'd argue is definitely not appropriate in this case. I really think that this one is border-line. Not useless at all, but should only trigger at a higher level so that users don't have to get rid of -Warray-bounds just because of it. The linux kernel already had to disable it for other reasons and that's really sad in my opinion, which is why I'm trying hard to keep it. Thanks, Willy
next prev parent reply other threads:[~2021-01-05 11:34 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 [this message] 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
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-diXqgfUozm@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: linkBe 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).