public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Tue, 09 Feb 2021 11:33:34 +0000 [thread overview] Message-ID: <bug-98465-4-AuYpalCyzA@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98465-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:e14ea108faa6eba6a60a45ff0ca3099ce6ae45c2 commit r11-7146-ge14ea108faa6eba6a60a45ff0ca3099ce6ae45c2 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Feb 9 12:32:43 2021 +0100 string: Add a workaround for -Wstringop-overread false positives [PR98465] In the PR there are several possibilities how to improve _M_disjunct at least in certain cases so that the compiler can figure out at least in some cases where __s is provably disjunct from _M_data() ... _M_data() + this->size() but it is probably GCC 12 material. The false positive warning is on this particular copy, which is done for non-disjunct pointers when __len2 > __len1 and the __s >= __p + __len1, i.e. __s used to point to the characters moved through _S_move a few lines earlier by __len2 - __len1 characters up to make space. That is why the _S_copy source is __s + __len2 - __len1. Unfortunately, when the compiler can't prove objects are disjunct, that copying from __s + __len2 - __len1 of __len2 characters can very well mean accessing characters the source object (if it is not disjunct) provably can't have. The following patch works around that by making the _S_copy be a __p based pointer instead of __s based pointer. __s + __len2 - __len1 and __p + (__s - __p) + (__len2 - __len1) have the same value and the latter may seem to be uselessly longer, but it seems at least currently in GIMPLE we keep it that way and so that is what the warning code during expansion will see, and only actually optimize it to __s + __len2 - __len1 during RTL when we lose information on what is a pointer and what is a mere offset with the same mode. So, in the end we emit exactly the same assembly, just without the false positive warning. 2021-02-09 Jakub Jelinek <jakub@redhat.com> PR middle-end/98465 * include/bits/basic_string.tcc (basic_string::_M_replace): When __s points to the characters moved by earlier _S_move, compute the source address using expression based on the __p pointer rather than __s pointer. * g++.dg/warn/Wstringop-overread-1.C: New test.
next prev parent reply other threads:[~2021-02-09 11:33 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-28 18:36 [Bug middle-end/98465] New: Bogus warning stringop-overread wuth " romain.geissler at amadeus dot com 2020-12-28 20:54 ` [Bug middle-end/98465] " msebor at gcc dot gnu.org 2020-12-30 12:49 ` romain.geissler at amadeus dot com 2020-12-30 13:22 ` romain.geissler at amadeus dot com 2020-12-30 21:25 ` msebor at gcc dot gnu.org 2021-01-06 22:38 ` msebor at gcc dot gnu.org 2021-01-06 22:59 ` msebor at gcc dot gnu.org 2021-01-06 23:14 ` msebor at gcc dot gnu.org 2021-01-07 20:26 ` msebor at gcc dot gnu.org 2021-01-13 18:19 ` msebor at gcc dot gnu.org 2021-01-13 18:41 ` law at redhat dot com 2021-01-13 18:52 ` jakub at gcc dot gnu.org 2021-01-13 19:02 ` msebor at gcc dot gnu.org 2021-01-13 19:14 ` jakub at gcc dot gnu.org 2021-01-13 19:30 ` msebor at gcc dot gnu.org 2021-01-14 2:21 ` msebor at gcc dot gnu.org 2021-01-19 19:00 ` msebor at gcc dot gnu.org 2021-01-20 23:20 ` [Bug middle-end/98465] [11 Regression] Bogus -Wstringop-overread with " msebor at gcc dot gnu.org 2021-02-04 14:03 ` jakub at gcc dot gnu.org 2021-02-04 14:39 ` redi at gcc dot gnu.org 2021-02-04 15:25 ` jakub at gcc dot gnu.org 2021-02-04 15:53 ` redi at gcc dot gnu.org 2021-02-04 15:54 ` redi at gcc dot gnu.org 2021-02-04 16:02 ` msebor at gcc dot gnu.org 2021-02-04 16:58 ` jakub at gcc dot gnu.org 2021-02-04 17:12 ` jakub at gcc dot gnu.org 2021-02-04 20:57 ` msebor at gcc dot gnu.org 2021-02-04 21:09 ` jakub at gcc dot gnu.org 2021-02-05 10:15 ` jakub at gcc dot gnu.org 2021-02-08 18:51 ` jakub at gcc dot gnu.org 2021-02-09 11:33 ` cvs-commit at gcc dot gnu.org [this message] 2021-02-09 11:35 ` [Bug middle-end/98465] " jakub at gcc dot gnu.org 2021-02-19 23:41 ` msebor at gcc dot gnu.org 2021-11-12 19:53 ` msebor at gcc dot gnu.org 2022-02-15 3:55 ` Randy at miningrigrentals dot com 2022-02-15 9:47 ` redi at gcc dot gnu.org 2022-02-15 9:55 ` Randy at miningrigrentals dot com 2022-02-15 10:02 ` redi at gcc dot gnu.org 2022-02-15 10:50 ` Randy at miningrigrentals dot com 2022-02-15 12:29 ` redi at gcc dot gnu.org 2022-02-15 12:40 ` Randy at miningrigrentals dot com 2022-02-15 12:52 ` redi at gcc dot gnu.org 2022-02-15 19:23 ` Randy at miningrigrentals dot com 2022-02-17 10:37 ` redi 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-98465-4-AuYpalCyzA@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).