From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 13CCC3858C60; Thu, 3 Mar 2022 16:09:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13CCC3858C60 From: "amacleod at redhat dot com" 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 16:09:00 +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: amacleod at redhat dot com 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: Thu, 03 Mar 2022 16:09:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104475 --- Comment #4 from Andrew Macleod --- (In reply to Aldy Hernandez from comment #3) > This isn't the threader but VRP/ranger. >=20 > What happens is that the threader isolates the path, making it easier for > VRP to see the equivalence, and then CCP4 folds the constant into the > problematic call. This is from the .ccp4 pass: >=20 > Folding statement: __atomic_or_fetch_4 (pretmp_29, 64, 0); > Folded into: __atomic_or_fetch_4 (184B, 64, 0); >=20 > In VRP2 the ranger is folding: >=20 > Folding statement: pretmp_29 =3D &MEM[(struct __atomic_base *)_1 + 184B].= _M_i; > Folded into: pretmp_29 =3D 184B; >=20 > The ranger is determining that _1 is 0 because it has determined that sin= ce > _2 is 0 on the 2->3 edge, so is _1, as m_mutex is the first field of _1: >=20 > =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%] >=20 > 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] >=20 > Andrew, how/where is that we relate _1 and _2 here? I can't seem to find= it. >=20 > My gut feeling is that special casing anything in the ranger for this is > wrong. Its via op1_range for OP_ADDR:=20=20 --param=3Dranger-debug=3Dtracegori shows: 2120 GORI outgoing_edge for _1 on edge 2->3 2121 GORI compute op 1 (_2) at if (_2 !=3D 0B) GORI LHS =3Dbool [0, 0] GORI Computes _2 =3D struct QMutex * [0B, 0B] intersect Known = range : struct QMutex * VARYING GORI TRUE : (2121) produces (_2) struct QMutex * [0B, 0B] 2122 GORI compute op 1 (_1) at _2 =3D &_1->m_mutex; GORI LHS =3Dstruct QMutex * [0B, 0B] GORI Computes _1 =3D struct QFutureInterfaceBasePrivate * [0B,= 0B] intersect Known range : struct QFutureInterfaceBasePrivate * VARYING GORI TRUE : (2122) produces (_1) struct QFutureInterfaceBasePri= vate * [0B, 0B] GORI TRUE : (2120) outgoing_edge (_1) struct QFutureInterfaceBasePrivate * [0B, 0B] so with _2 =3D=3D 0, the 2122 trace element is solving for _1 in _2 =3D &_1->m_mutex [0,0] =3D &_1->m_mutex is it possible for _1 to be anything other than 0 in this case? If so we = need to adjust range-ops=