From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 3CD8A38A7C10; Wed,  7 Dec 2022 09:46:16 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3CD8A38A7C10
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670406376;
	bh=tmbxYZAgM+uB0kSq61bOIv0QiKmlEmjIqGTumjQpHAs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=BFpTHQMzArISuA7oSYtYFD/c3SIJKOCCjDd9U+t2asvBXdlEiyxo9cxpERmaFcWO4
	 Dc9dzU6jUNHH9ZUBeViow74WhIzGU0lVtT2gHz/TdtBMwt4XRkWrk+8HO3NkTFig8R
	 aXXsqM/DwFVklIXrwGkbVDGj6C/dYkjVN/IloAnE=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow
 + atomics incorrect warning on dynamic object
Date: Wed, 07 Dec 2022 09:46:02 +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: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-104475-4-n3XIgI6Jru@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104475-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104475-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104475

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thiago Macieira from comment #19)
> (In reply to Richard Biener from comment #15)
> > Thanks, it's still the same reason - we isolate a nullptr case and end =
up
> > with
> >=20
> > __atomic_or_fetch_4 (184B, 64, 0); [tail call]
> >=20
> > The path we isolate is d->m_mutex =3D=3D nullptr && !enable in
> >=20
> > void QFutureInterfaceBase::setThrottled(bool enable)
> > {
> >     QMutexLocker lock(&d->m_mutex);
>=20
> Thank you for the analysis, Richard. But do note that it's &d->m_mutex, n=
ot
> d->m_mutex that is passed to the locker. C++ says that if you do d-> then=
 d
> !=3D nullptr, so &d->m_mutex can't be nullptr either.

Hmm, I see

<bb 2> [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)

so we load the pointer 'this_10(D)->d' and then indeed check &d->m_mutex
for being NULL.

The middle-end long allowed &nullptr->x for the sake of legacy code
implementing offsetof by pointer arithmetic on an object at NULL.

Given

struct X { int a; int b ; };
int foo (struct X *x)
{
  return &x->a !=3D (int *)0;
}

we do indeed not simplify this.  Doing &x->b !=3D (int *)0 shows even that
is only simplified by recent code in Ranger (via DOM at -O1 or VRP at -O2).
That's also true for the

struct X { int a; int b ; };
int foo (struct X *x)
{
  int *p =3D (int *)x + 1;
  return p !=3D (int *)0;
}

variant.  Special-casing this in the language frontends probably won't
fix the testcase since the use in a nullptr comparison is hidden
via a function call of the CTOR:

    QMutexLocker lock(&d->m_mutex);

and as you say m_mutex is at offset zero.

Since consider pointer overflow undefined we should be able to optimize
&x->b !=3D nullptr in the middle-end earlier and more consistently.  The
offset zero case is harder since we consider &x->b as just pointer
arithmetic and x + 0 !=3D nullptr cannot be optimized I think.=