From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3EBF33857831; Fri, 15 Jul 2022 15:42:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EBF33857831 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/105746] vector::resize causes Warray-bounds when optimizer uses __builtin_memcpy or __builtin_memmove since r12-2793-g81d6cdd335ffc60c Date: Fri, 15 Jul 2022 15:42:52 +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: 10.1.1 X-Bugzilla-Keywords: diagnostic 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: component 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: Fri, 15 Jul 2022 15:42:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105746 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c++ |middle-end --- Comment #2 from Martin Sebor --- The memmove call in the IL the warning is issued for writes past the end of= the allocated block. My guess is that the call to operator new prevents it from figuring out that the _M_finish initially zeroed out by the vectorized stor= e to vectp.132_96 is still clear in bb 5. This can be confirmed by replacing the call to operator new with one to __builtin_malloc() which both eliminates t= he warning and also results in much more efficient code(*). There are duplica= tes of this problem in Bugzilla. The root cause is probably the fix for pr1014= 80. [local count: 1073741824]: vectp.132_96 =3D &MEM[(struct _Vector_impl_data *)v_2(D)]._M_start; MEM [(union U * *)vectp.132_96] =3D { 0, 0 = };=20=20 <<< zero out _M_finish (and _M_start) MEM[(struct _Vector_impl_data *)v_2(D)]._M_end_of_storage =3D 0B; _70 =3D operator new (100); [local count: 1073741824]: __builtin_memset (_70, 255, 100); _78 =3D v_2(D)->D.25350._M_impl.D.24657._M_start; <<< zero if (_78 !=3D 0B) goto ; [89.00%] else goto ; [11.00%] [local count: 439275554]: <<< unreachable=20 # __cur_127 =3D PHI <__cur_83(4), _70(3)> # __first_120 =3D PHI <__first_82(4), _78(3)> *__cur_127 =3D{v} {CLOBBER}; _81 =3D MEM[(const union U &)__first_120]; MEM[(union U *)__cur_127] =3D _81; __first_82 =3D __first_120 + 1; __cur_83 =3D __cur_127 + 1; goto ; [100.00%] [local count: 54292484]: __new_finish_85 =3D _70 + 100; _86 =3D v_2(D)->D.25350._M_impl.D.24657._M_finish; <<< zero if (_86 !=3D 0B) goto ; [89.00%] else goto ; [11.00%] [local count: 48320311]: <<< unreachable _93 =3D (sizetype) _86; <<< zero __builtin_memmove (__new_finish_85, 0B, _93); <<< warning ... The IL for the function when operator new is replaced with __builtin_malloc: struct vector bug () { union U * __new_finish; union U * __cur; long unsigned int __n; union U * _70; [local count: 1073741824]: _70 =3D __builtin_malloc (100); __builtin_memset (_70, 255, 100); __new_finish_84 =3D _70 + 100; v_2(D)->D.25350._M_impl.D.24657._M_start =3D _70; v_2(D)->D.25350._M_impl.D.24657._M_finish =3D __new_finish_84; v_2(D)->D.25350._M_impl.D.24657._M_end_of_storage =3D __new_finish_84; return v_2(D); }=