https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> There's also the following weak heuristic that might kick in if
> CONSTRUCTOR_NO_CLEARING would be set:
>
> else if (num_ctor_elements - num_nonzero_elements
> > CLEAR_RATIO (optimize_function_for_speed_p (cfun))
> && num_nonzero_elements < num_ctor_elements / 4)
> /* If there are "lots" of zeros, it's more efficient to clear
> the memory and then set the nonzero elements. */
> cleared = true;
>
> with CONSTRUCTOR_NO_CLEARING this heuristic is off by not honoring
> the constructor elements being not present (but for the testcase it
> doesn't matter). CCing Eric for this specific issue (not the C++ one).
Ugh. I didn't write this but, yes, there is an oversight, the check on the
flag should probably be on entry instead:
if (CONSTRUCTOR_NO_CLEARING (ctor))
cleared = false;
else if (int_size_in_bytes (TREE_TYPE (ctor)) < 0)
...
else if
