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 830233858404; Fri, 31 Mar 2023 09:52:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 830233858404
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680256332;
	bh=FiQyEIxbb6byy9p90p4KOh3wqHioaR1a3pbflKrxVas=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Uvpbj+eAKIyg5uO9uSQLa/yk+5ZSs8eLAZWG7ZR7opbupQGI3jluXJfpgB+msGrWB
	 zD9C1uSDrsEocxhYtTfnF305tQWGNaEj/fP5Bemq/rVrTDZnEd4tiL/CYrDOhdqhB2
	 SQvEYV7qAo9SUTgIz+T7w9OnIAQiqsT2tAGtxLHo=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/109339] [12/13 Regression] stop_token compiled with
 -Og yields maybe-uninitialized
Date: Fri, 31 Mar 2023 09:52:11 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109339-4-cVRimVF6S0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109339-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109339-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=3D109339

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> The diagnostic is intentional I think.  We see
>=20
> <bb 2> [local count: 1073741824]:
> ss =3D{v} {CLOBBER};
> std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
> std::stop_source::~stop_source (&ss);
> ss =3D{v} {CLOBBER(eol)};
> return 0;
>=20
> and the call to _Stop_state_ref passes references to uninitialized 'ss'
> (tree-ssa-uninit.cc:maybe_warn_pass_by_reference).  The &ss argument
> is a const reference and the function does
>=20
>       _Stop_state_ref(const _Stop_state_ref& __other) noexcept

That function is never used in this code though. Why is code being emitted =
for
it?

We don't copy a _Stop_state_ref, we construct one using this constructor:

      _Stop_state_ref(const stop_source&)
      : _M_ptr(new _Stop_state_t())
      { }

This has a reference to ss but doesn't inspect it at all.


>       : _M_ptr(__other._M_ptr)
>       {
>  if (_M_ptr)
>    _M_ptr->_M_add_owner();
>       }
>=20
> so it inspects __other._M_ptr.  It looks like for some reason the NSDMI
> init of _M_ptr isn't happening?

Because an NSDMI is not used if the constructor inits it explicitly, like t=
his
one does. But this constructor is never used anyway, it's an unused inline
function so should not be emitted, and we should not get warnings for it.=