[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 16 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Well, for the .DEFERRED_INIT case if the var ends up in memory, I really don't
> see the point in any clear_padding, .DEFERRED_INIT expansion should just
> initialize the whole DECL_RTL MEM_P slot with the pattern it wants, trying to
> initialize only the non-padding bits and then only the padding bits next to
> each other is a waste of CPU cycles.
> Another case are C++ vars with non-trivial ctors, if we for -flifetime-dse=2
> emit CLOBBERs at the start of such ctors, then IMNSHO the right thing is to
> emit the zero or pattern initialization in those constructors, perhaps through
> .DEFERRED_INIT.
> This is the start_preparsed_function
>   if (!processing_template_decl
>       && (flag_lifetime_dse > 1)
>       && DECL_CONSTRUCTOR_P (decl1)
>       && !DECL_CLONED_FUNCTION_P (decl1)
>       /* Clobbering an empty base is harmful if it overlays real data.  */
>       && !is_empty_class (current_class_type)
>       /* We can't clobber safely for an implicitly-defined default constructor
>          because part of the initialization might happen before we enter the
>          constructor, via AGGR_INIT_ZERO_FIRST (c++/68006).  */
>       && !implicit_default_ctor_p (decl1))
>     finish_expr_stmt (build_clobber_this ());
> case.  Advantage of doing it in the ctor is that if it isn't inlined, it is
> done just once per type, doesn't need to be duplicated in all the spots that
> use it.
> Of course, if the above conditions aren't met, then it still needs to be
> initialized somewhere else like where it is done currently, or for the case of
> vars with constructors for which we don't emit it perhaps do
> __builtin_clear_padding after the constructor (but can we be sure that the ctor
> hasn't e.g. performed placement new and built in itself some other class?).
> 
> Anyway, doing __builtin_clear_padding at RTL expansion time might be
> non-trivial.  One thing we still haven't decided on what to do with the virtual
> inheritance, whether we need a langhook which won't be there at expansion time,
> or if we can just use binfo (but doesn't free_lang_data mess up with binfo
> too)?
> And right now the code has two main possibilities, either emit gimple code to
> do the clearing, or set a padding bitmask in memory.  For RTL, either one could
> use the latter and turn that into RTL code clearing, or we would need a third
> mode in which it would be emitting RTL directly.  Emitting such code early has
> the advantage of store-merging and all kinds of other optimizations though...

There's also the option to do .DEFERRED_INIT expansion on GIMPLE 
somewhere, maybe in ISEL.  But sure, if padding clearing needs a langhook
that's a no-go.  BINFOs are preserved to the extent needed for
devirtualization.  I suppose the mask could also be precomputed and
stuck into the .DEFERRED_INIT call itself somehow ... (encoded into
some sequence of variable number of args? <offset>, <mask>, <offset>, 
<mask>, 0)