From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 255D53858418; Mon, 2 May 2022 13:33:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 255D53858418 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6 Date: Mon, 02 May 2022 13:33:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 12.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: Mon, 02 May 2022 13:33:22 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105329 --- Comment #13 from Jakub Jelinek --- I think this is quite related to the PR98465 discussions. The warning is on dead code, for basic_string at least when using reasonable allocators the _M_dataplus._M_p member will always point either into the _M_local_buf embedded buffer, or to something that has been allocated by the allocator. In particular, it should never point into .rodata objects, or w= hen using a reasonable allocator to global or automatic vars (with the exceptio= n of the embedded buffer). There is the _M_disjunct method that returns whether the std::string could overlap with the second argument, if we'd say through some magic attribute = on the _M_dataplus._M_p were able to tell the optimizers perhaps through a builtin that there is no overlap, we would optimize away the dead code and = be fine (not just for the questionable warnings, but more importantly for code generation as well). Another approach to deal with this exact case might be some builtin that wo= uld find out if the argument must be in read-only memory ("5" in this case) and= use that as an additional check in _M_disjunct, say that then the arg must be read-only, it must be disjunct because the string is necessarily writable. As has been discussed, yet another possibility would be to handle the rare = case (not disjunct) in out of line (ideally libstdc++.so.6 contained (at least f= or the usual instantiations)) code, which would also make the rare case smaller and such warnings not really visible to the optimizers.=