https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
Last reconfirmed| |2022-09-13
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |12.3
Blocks| |24639
Ever confirmed|0 |1
Keywords| |diagnostic,
| |missed-optimization
Summary|[12 Regression] Bogus |[12/13 Regression] Bogus
|uninitialized warning on |uninitialized warning on
|boost::optional<<std::vecto |boost::optional<<std::vecto
|r<std::string>>> |r<std::string>>>
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed also on trunk and also with -O1 and the usual suspects -fno-ivopts
-fno-thread-jumps.
The question is whether
external = internal;
is problematic. For example
struct MyStruct { };
std::vector<MyStruct> getMyStructs();
void test()
{
Optional<std::vector<std::string>> external;
Optional<std::vector<std::string>> internal;
external = internal;
}
is diagnosed with -std=c++20 -O -Wuninitialized -fno-tree-fre
-fno-tree-dominator-opts
that's because we then no longer forward the uninit state of the Optionals
and thus diagnose the conditional (on initialized)
<bb 6> [local count: 118702158]:
_34 = MEM[(struct vector *)&external + 8B].D.88471._M_impl.D.87778._M_finish;
_35 = MEM[(struct vector *)&external + 8B].D.88471._M_impl.D.87778._M_start;
if (_34 != _35)
goto <bb 41>; [89.00%]
...
the same happens with the unreduced testcase, there we have similar code
conditional on external.m_initialized where we are not able to forward
the m_initialized state.
It might be the bisected rev. causes a missed optimization here, I will have
to check. At least I don't see a good reason why we don't forward it here.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
