https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
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 ={v} {CLOBBER};
std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
std::stop_source::~stop_source (&ss);
ss ={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 = {CLOBBER} >>>>>;
{
<<cleanup_point <<< Unknown tree: expr_stmt
std::stop_token::_Stop_state_ref::_Stop_state_ref (&((struct stop_source *)
this)->_M_state, (const struct stop_source &) this) >>>>>;
try
{
}
catch
{
std::stop_token::_Stop_state_ref::~_Stop_state_ref (&((struct stop_source
*) 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.
