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 31D373954477; Tue,  6 Dec 2022 08:17:56 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31D373954477
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670314676;
	bh=gkmrMPlDC+mDWfBj+XI9BcgIdOxsohwmZDBuHnDuwCo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nhqT/E88UXl0hQjLZJfPtvGxldd2XGhu+/EwcT8ojNAEyNVvtMwXpDv9dGbhnLz6q
	 DVDJ5eWlZcoSSNQpqbWPcj5YxX2ymQigZvTdlKRnUBeB0PQmszF+pEZpK4Bf4ETNEV
	 aqtjQafympLBalYi0oysAm48GKtQ200r67HZ/3Yg=
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: Tue, 06 Dec 2022 08:17:51 +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: 
Message-ID: <bug-104475-4-CWtqxpK3lT@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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Thanks, it's still the same reason - we isolate a nullptr case and end up w=
ith

__atomic_or_fetch_4 (184B, 64, 0); [tail call]

The path we isolate is d->m_mutex =3D=3D nullptr && !enable in

void QFutureInterfaceBase::setThrottled(bool enable)
{
    QMutexLocker lock(&d->m_mutex);
    if (enable) {
        switch_on(d->state, Throttled);
    } else {
        switch_off(d->state, Throttled);
        if (!(d->state.loadRelaxed() & suspendingOrSuspended))
            d->pausedWaitCondition.wakeAll();
    }
}

where for unknown reason QMutexLocker happily allows a nullptr mutex
(it's documented that way)

    inline explicit QMutexLocker(Mutex *mutex) noexcept
    {
        m =3D mutex;
        if (__builtin_expect(!!(mutex), true)) {
            mutex->lock();
            isLocked =3D true;
        }
    }

we predict the path to be unlikely but the adjustment to the threader
covered probably never executed paths (with probability zero).  The
threading opportunity arises because the DTOR calls

    inline void unlock() noexcept
    {=20=20=20
        if (!isLocked)
            return;
        m->unlock();
        isLocked =3D false;
    }

and we know isLocked on the nullptr path.

I thought we could maybe enhance prediction to look for nullptr based
accesses but at the time we estimate probabilities the QMutexLocker
CTOR isn't yet inlined (the DTOR is partially inlined, exposing the
isLocked check).

Note the "impossible" path is actually in the sources - so there might
be a missing conditional somewhere.=