public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hacatu5000 at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/109980] New: Bogus Wstringop-overflow and Wstringop-overread warnings when attribute `access` is applied to struct arg Date: Fri, 26 May 2023 07:47:56 +0000 [thread overview] Message-ID: <bug-109980-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109980 Bug ID: 109980 Summary: Bogus Wstringop-overflow and Wstringop-overread warnings when attribute `access` is applied to struct arg Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hacatu5000 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I'm getting incorrect warnings for some functions using the `access` attribute. I've managed to reduce the code that produces the error to this: ========== access.c ========== typedef struct{ int value, decoy; } S; [[gnu::access(read_write, 1)]] int S_rw(S *self){ return self->value += 1; } [[gnu::access(read_only, 1)]] int S_ro(const S *self){ return self->value; } int S_test(S *tmps){ return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1); } ==================== ========== compiler options (13.1.1 20230429 x86_64-pc-linux-gnu) ========== gcc -std=c2x -fsanitize=object-size -O1 -c access.c ==================== ========== output ========== access.c: In function ‘S_test’: access.c:16:33: warning: ‘S_rw’ accessing 8 bytes in a region of size 4 [-Wstringop-overflow=] 16 | return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1); | ^~~~~~~~~~~~~~ access.c:6:5: note: in a call to function ‘S_rw’ declared with attribute ‘access (read_write, 1)’ 6 | int S_rw(S *self){ | ^~~~ access.c:16:51: warning: ‘S_ro’ reading 8 bytes from a region of size 4 [-Wstringop-overread] 16 | return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1); | ^~~~~~~~~~~~~~ access.c:2:13: note: source object ‘value’ of size 4 2 | int value, decoy; | ^~~~~ access.c:11:5: note: in a call to function ‘S_ro’ declared with attribute ‘access (read_only, 1)’ 11 | int S_ro(const S *self){ | ==================== These incorrect warnings occur regardless of -Wall, -Wextra, and -fno-strict-aliasing. However, the warnings go away if I remove ANY OF: - the field `decoy` - the `access` annotations - the `tmps[1].value` argument to `&&` - `-fsanitize=object-size` - `-O1` This looks extremely similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689 but I do not get bogus warnings at `-O2`, only with `-fsanitize=object-size` (an `-O1`). In fact, these warnings GO AWAY when I use both `-fsanitize=object-size` and `-O2`. Additionally, I'm seeing invalid -Wstringop-overread, not just -Wstringop-overflow, although the latter is probably caused by the same CSE bug that causes these very similar warnings in slightly different circumstances.
next reply other threads:[~2023-05-26 7:47 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-26 7:47 hacatu5000 at gmail dot com [this message] 2023-05-27 1:39 ` [Bug sanitizer/109980] " pinskia 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-109980-4@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).