https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116416
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #6)
> Thanks. Yeah, it was approved. But I still see
>
> FAIL: g++.dg/tree-ssa/pr78687.C scan-tree-dump sra "Removing load:.*ptr;"
>
> even once I've rebased my patch. Weird, because the FAIL *was* gone when I
> tried your patch a few weeks ago.
Guess it would pass with just r15-5746 + your
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664680.html
patch, but not with r15-5747 .
inline ref_proxy<option_2, option_ref > make_object_1()
{
return ref_proxy<option_2, option_ref >(option_2());
}
I think option_2() above is value initialization and zero initialization in
that case given that it is
struct option_2
{
};
and so we are required to zero initialize even the padding bits (sizeof
(option_2) == 1, so that exact byte).
So, can we perhaps commit with xfailing that testcase?
Martin, could you please have a look what could be done on the SRA side?
I'm afraid with the r15-5746 + r15-5747 changes there might be more zero
initialization of the padding bits than in the past (ditto for the optimization
Alexandre added for small aggregates with padding bits) and it would be nice if
SRA was still able to optimize it assuming it can prove nothing really attempts
to read the padding bits etc., basically just add some smart handling of = {};
initialization.
