From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EBE3A3858010; Thu, 2 Dec 2021 23:19:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBE3A3858010 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation Date: Thu, 02 Dec 2021 23:19:46 +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: 12.0 X-Bugzilla-Keywords: alias, diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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, 02 Dec 2021 23:19:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103534 --- Comment #4 from Martin Sebor --- Yes, the warning does disappear when malloc() and free() are used instead of operator new and delete. foo() also ends up much better optimized, even at -O1: __attribute__((abi_tag ("cxx11"))) struct string foo () { struct string & _7(D); char * _69; [local count: 1073741824]: _69 =3D __builtin_malloc (17); __builtin_memcpy (_69, "1234567890123456", 16); MEM[(char_type &)_69 + 16] =3D 0; MEM[(struct basic_string *)_7(D)]._M_dataplus._M_p =3D _69; MEM[(struct basic_string *)_7(D)].D.33183._M_allocated_capacity =3D 16; MEM[(struct basic_string *)_7(D)]._M_string_length =3D 16; return _7(D); } The -O1 dump in comment #1 doesn't look right, I may have messed something = up.=20 The same issue happens at -O2 where the dump is as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: n_5(D)=20=20 Exports: _1 n_5(D)=20=20 _1 : n_5(D)(I)=20=20 n_5(D) int [-INF, -1][1, +INF] [local count: 536870913]: _1 =3D (sizetype) n_5(D); if (_1 =3D=3D 1) goto ; [51.12%] else goto ; [48.88%] _1 : sizetype [1, 2147483647][18446744071562067968, +INF] 3->4 (T) _1 : sizetype [1, 1] 3->4 (T) n_5(D) : int [1, 1] 3->5 (F) _1 : sizetype [2, 2147483647][18446744071562067968, +INF] 3->5 (F) n_5(D) : int [-INF, -1][2, +INF] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [local count: 274448412]: MEM[(char *)&b] =3D 0; goto ; [100.00%] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [local count: 262422500]: __builtin_memcpy (&b, &a, _1);=