From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B89733AAB013; Thu, 4 Feb 2021 14:39:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B89733AAB013 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert Date: Thu, 04 Feb 2021 14:39:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: alias, diagnostic, missed-optimization, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: msebor 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: Thu, 04 Feb 2021 14:39:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98465 --- Comment #19 from Jonathan Wakely --- A new built-in seems like a very large hammer to solve this problem, which should really be implementable in quite simple pure C++. (In reply to Jakub Jelinek from comment #18) > So, can some template stuff ensure that the builtin would be only used wh= en > using a standard allocator and not something that can say have a global: > char buffer[0x10000000]; and allocate from that? Yes, that's pretty easy. Just check it's std::allocator and the char_type is one of char, wchar_t, char16_t etc. Ugly, but easy. > Pass to the builtin all the needed info (e.g. > return __builtin_whatever_disjunct (_M_data(), this->size(), > _M_local_data(), __s); > ) and let it use points to info to fold it to false if the last pointer > can't point to either _M_local_data() pointed object or heap memory, > otherwise fold into pointer sized casts of the pointers and integral > comparisons as before? But isn't it going to be fairly common that __s points to heap memory? Or d= o we not care about that case, because the false positive warning only happens f= or non-heap memory? Tangentially, maybe we could improve _M_disjunct by passing it the length of __s, which all callers have available. If that length is larger than this->size() then we don't need the pointer comparisons. If __s points into= the string, then it can't extend past the end of the string. Would the built-in be simpler and/or more useful elsewhere if it took two pointers and two lengths, and determined if one region is entirely contained within the other?=