https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116416
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Of course we could also try to get smarter at gimplification time.
We have
{._storage={.D.9582={.D.9163={._tail={.D.9221={._tail={.D.9280={._head={}}}}}}},
._which=2}}
ctor and the only CONSTRUCTOR_ZERO_PADDING_BITS ctor is that {}, for 1-byte
empty structure, while the whole structure has 48 bytes, so we could also
gimplify it as
D.10137._storage..D.9582.D.9163._tail.D.9221._tail.D.9280._head = {};
D.10137._storage._which = 2;
rather than
D.10137 = {};
D.10137._storage._which = 2;
But we'd need to figure out not just that there is padding, but also how much
padding we need to clear, how consecutive or non-consecutive it is, etc.
Maybe as a hack just let the code handle one special case, if there is just one
sub-field which needs zero padding, only zero initialize that, if there are 2+,
zero it all.
Changing
- return ref_proxy<option_2, option_ref >(option_2());
+ return ref_proxy<option_2, option_ref >(option_2{});
in the testcase also achieves the same effect.
