From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C06D23857003; Tue, 5 Jan 2021 11:34:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C06D23857003 From: "w at 1wt dot eu" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: w at 1wt dot eu X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 11:34:45 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98503 --- Comment #9 from Willy Tarreau --- Hi Richard, indeed, the &curr->list =3D=3D &head is the test for end of list that preve= nts 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 o= nly 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, wh= ich 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 try= ing hard to keep it. Thanks, Willy=