From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD5F83858D39; Thu, 3 Mar 2022 14:00:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD5F83858D39 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object Date: Thu, 03 Mar 2022 14:00:53 +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, needs-reduction X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh 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: cc 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, 03 Mar 2022 14:00:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104475 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #3 from Aldy Hernandez --- This isn't the threader but VRP/ranger. What happens is that the threader isolates the path, making it easier for V= RP to see the equivalence, and then CCP4 folds the constant into the problemat= ic call. This is from the .ccp4 pass: Folding statement: __atomic_or_fetch_4 (pretmp_29, 64, 0); Folded into: __atomic_or_fetch_4 (184B, 64, 0); In VRP2 the ranger is folding: Folding statement: pretmp_29 =3D &MEM[(struct __atomic_base *)_1 + 184B]._M= _i; Folded into: pretmp_29 =3D 184B; The ranger is determining that _1 is 0 because it has determined that since= _2 is 0 on the 2->3 edge, so is _1, as m_mutex is the first field of _1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: _1=20=20 Exports: _1 _2=20=20 _2 : _1(I)=20=20 [local count: 1073741824]: _1 =3D this_10(D)->d; _2 =3D &_1->m_mutex; MEM[(struct __as_base &)&lock] =3D{v} {CLOBBER}; if (_2 !=3D 0B) goto ; [90.00%] else goto ; [10.00%] 2->5 (T) _1 : struct QFutureInterfaceBasePrivate * [1B, +INF] 2->5 (T) _2 : struct QMutex * [1B, +INF] 2->3 (F) _1 : struct QFutureInterfaceBasePrivate * [0B, 0B] 2->3 (F) _2 : struct QMutex * [0B, 0B] Andrew, how/where is that we relate _1 and _2 here? I can't seem to find i= t. My gut feeling is that special casing anything in the ranger for this is wr= ong.=