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 819483858CDB; Thu, 30 Mar 2023 07:39:54 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 819483858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680161994;
	bh=IUYL+KPkOnQXCOt2zBdlO/cjfuMSHuutlTpM07yr3Ds=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=WiDUQSAsr207ox344qwVW1GZeaFBSsr4zMS8Oxe8xMiHw/lzaGwtm5Tlgn+xUbV8m
	 v335d14Fd61Tbyhoi1bnAHKv5SvRVr03dp37+eUuKiTsVGJYuVYBnG6lZ+yPFHGiRK
	 pOWxzWrin2uEWIb2ULRR7nKP2D9HRXQzO4JGBUjo=
From: "rguenth 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: Thu, 30 Mar 2023 07:39:54 +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: rguenth 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: component
Message-ID: <bug-109339-4-9kNMd8t1KT@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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |libstdc++

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The diagnostic is intentional I think.  We see

<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;

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

      _Stop_state_ref(const _Stop_state_ref& __other) noexcept
      : _M_ptr(__other._M_ptr)
      {
 if (_M_ptr)
   _M_ptr->_M_add_owner();
      }

so it inspects __other._M_ptr.  It looks like for some reason the NSDMI
init of _M_ptr isn't happening?

The FE emits

;; Function std::stop_source::stop_source() (null)
;; enabled by -tree-original


<<cleanup_point <<< Unknown tree: expr_stmt
  *(struct stop_source *) this =3D {CLOBBER} >>>>>;
{
  <<cleanup_point <<< Unknown tree: expr_stmt
    std::stop_token::_Stop_state_ref::_Stop_state_ref (&((struct stop_sourc=
e *)
this)->_M_state, (const struct stop_source &) this) >>>>>;
  try
    {

    }
  catch
    {
      std::stop_token::_Stop_state_ref::~_Stop_state_ref (&((struct stop_so=
urce
*) this)->_M_state);
    }
}

but it's all a bit convoluted?  To me it looks like a library issue.  Yes,
with more inlining we optimize everything away.=