public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sciresm.gccbugzilla at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/100309] New: [11 regression] false positive -Wstringop-overflow/stringop-overread/array-bounds on reinterpret_cast'd integers Date: Wed, 28 Apr 2021 08:27:18 +0000 [thread overview] Message-ID: <bug-100309-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100309 Bug ID: 100309 Summary: [11 regression] false positive -Wstringop-overflow/stringop-overread/array-bounds on reinterpret_cast'd integers Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sciresm.gccbugzilla at gmail dot com Target Milestone: --- Created attachment 50697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50697&action=edit Minimal test case code. Bug occurs in GCC 11.1.0, but none of the 10.x releases. It appears that GCC is now inferring a size of 0 when doing reinterpret_cast<void*>(ConstantInteger); when doing std::memcpy/std::memset to/from the result pointers, bogus warnings are emitted about reading/writing to regions of zero size. My target is an embedded system with a fixed memory layout; I have been using constexpr uintptr_t/size_ts's to describe the memory regions, and correspondingly calls to set or copy memory regions are now emitting bogus warnings. I have made an example minimal test case here (also attached): https://godbolt.org/z/WPaGY8eaz Relevant errors (compiling with -O -Werror): void StringopOverread() { // error: 'void* memset(void*, int, size_t)' writing 16 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] std::memset(reinterpret_cast<void *>(0xCAFEBABE), 0xCC, 0x10); } void StringopOverflow2(const void *src) { // error: 'void* memcpy(void*, const void*, size_t)' writing 16 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] std::memcpy(reinterpret_cast<void *>(0xCAFEBABE), src, 0x10); } void StringopOverread(void *dst) { // error: 'void* memcpy(void*, const void*, size_t)' reading 16 bytes from a region of size 0 [-Werror=stringop-overread] std::memcpy(dst, reinterpret_cast<void *>(0xCAFEBABE), 0x10); }
next reply other threads:[~2021-04-28 8:27 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-28 8:27 sciresm.gccbugzilla at gmail dot com [this message] 2021-04-28 8:38 ` [Bug c++/100309] " harald at gigawatt dot nl 2021-04-28 9:30 ` [Bug c++/100309] [11/12 " rguenth at gcc dot gnu.org 2021-04-28 16:11 ` [Bug middle-end/100309] " 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-100309-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).