https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92871
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-12-09
CC| |jason at gcc dot gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oops, I see what's going on.
The ?: with omitted middle operand is transformed earlier into
cp_stabilize_reference (arg1) ? cp_stabilize_reference (arg1) : ...
where the first two arguments are the same, then the middle argument is wrapped
into ADDR_EXPR (but I'd be afraid that generally it can be much harder to
figure out what is what) and only much later extend_ref_init_temps_1, which
only modifies the second argument (and third) and puts the subinit initializers
in there. While the tree of the TARGET_EXPR is obviously shared between the
first and second COND_EXPR arguments, as we put the initialization just into
the second, it means the VAR_DECL that replaced the TARGET_EXPR is used before
it is initialized.
Now, I'm afraid it will be nasty to fix it up.
Either we mark with some flag COND_EXPRs that had originally the middle operand
omitted, propagate it through all the COND_EXPR rationalization etc. and then
try to figure out how to get from the second operand something suitable for the
first operand if that is at all possible (e.g. in this testcase perhaps by
figuring out that originally the second argument is & of the first one and
after changing the second one, modify the first argument to be INDIRECT_REF of
the second one and thus get all the subinit initialization in there.
Or try to somehow discover if the first and second argument were originally the
same without a flag. Or make sure we keep the middle operand NULL much longer.
Any other ideas?
This problem isn't actually powerpc64 specific, on x86_64-linux, while we are
lucky that the test passes, valgrind shows that it uses uninitialized memory.
