From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 64DAB3858C5F; Thu, 11 May 2023 11:36:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64DAB3858C5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683804972; bh=1I2SJ7WUZ+Um4CK1wAXOumMp780b0yCVP7EyfYiFMk8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OWJT4+gtQJMtXvN0+2noReK7qEh2pIOUvW7/+UKXmU6ahFazo8oxYBA9UCNjxjVfu /Nn9r8WGhlNAOHtnM9UWKyKj9ngaExdKD9ORWhMByihvnboAHxLM8CtWvPeJp9cb+e ObMf9Pj4Js70+dp3jsQXtttM3rUyTjshQRV4NVJo= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0 Date: Thu, 11 May 2023 11:36:12 +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.1.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109791 --- Comment #7 from rguenther at suse dot de --- On Thu, 11 May 2023, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109791 >=20 > --- Comment #6 from Aldy Hernandez --- >=20 > > but the issue with the PHI node remains unless we sink the &str part > > (but there's many uses of __i_14). I guess it's still the "easiest" > > way to get rangers help. Aka make > >=20 > > # __i_14' =3D PHI <1(10), 2(9)> > > __i_14 =3D &str + __i_14'; // would be a POINTER_PLUS_EXPR > >=20 > > it's probably still not a complete fix but maybe a good start. Of cour= se > > it increases the number of stmts - &MEM[&str + 1B] was an 'invariant' > > (of course the PHI result isn't). There's not a good place for this > > transform - we never "fold" PHIs (and this would be an un-folding). >=20 > Ughh, that sucks. Let's see if Andrew has any ideas, but on my end I won= 't be > able to work on prange until much later this cycle-- assuming I finish wh= at I > have on my plate. So the idea with the above is of course that via regular folding and value-numbering we can simplify the compare to a compare of just the offsets and for those ranger already works. The expression is quite obfuscated of course and as said the strlen pass placement doesn't help (it's before forwprop and VRP). That said, the place to transform the PHI node is probably the same where degenerate PHIs are removed. For the testcase the PHI is created quite early by cunrolli. I have a patch splitting the PHI. We then still have # _69 =3D PHI <1(9), 2(8)> __i_44 =3D &str + _69; ... [local count: 402445658]: _51 =3D (unsigned long) &MEM [(void *)&str + 2B]; _4 =3D (unsigned long) __i_44; _12 =3D -_4; _119 =3D _51 + 18446744073709551615; _48 =3D _119 - _4; _46 =3D _48 > 13; if (_46 !=3D 0) goto ; [64.00%] and also _31 =3D &MEM [(void *)&str + 3B] <=3D __i_44; so at least for the latter we are missing a simplification pattern - it should simplify the compare to _31 =3D 3 <=3D _69 possibly (unsigned)(p p+ offset) should be changed to (unsigned)p + offset and thus likewise (unsigned) &MEM[&str + 4B] into (unsigned)&str + 4.=