On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > folding,
> > > but we don't do that anymore because ctor_for_folding etc. has been
> > > turned into a
> > > GIMPLE centric API, but as the testcase shows, it is invoked even during
> > > GENERIC folding and there the automatic vars still should have meaningful
> > > initializers. I've verified that the C++ FE drops TREE_READONLY on
> > > automatic vars with const qualified types if they require non-constant
> > > (runtime) initialization.
>
> > > --- gcc/varpool.c.jj 2021-01-26 08:57:36.184290279 +0100
> > > +++ gcc/varpool.c 2021-01-26 09:46:16.453619140 +0100
> > > @@ -412,6 +412,12 @@ ctor_for_folding (tree decl)
> > > if (!TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
> > > {
> > > gcc_assert (!TREE_PUBLIC (decl));
> > > + /* Unless this is called during FE folding. */
> > > + if (!in_gimple_form
> >
> > Wouldn't it be better to use symtab->state == PARSING? Why isn't
>
> That would work for me too, in_gimple_form is just what is normally used
> for the folding. And the routine is doing folding, but sits in a file where
> symtab->state == PARSING check is more natural.
>
> > it safe to always return DECL_INITIAL (but demote NULL to
> > error_mark_node and/or change the gimplifier to set it to
>
> I'm not sure if it is safe to look at DECL_INITIAL after gimplification for
> automatic vars because the gimplifier is destructive and could have changed
> the initializers in random ways. But I admit I haven't investigated whether
> e.g. debug info cares about DECL_INITIAL for automatic vars or not.
>
> Looking at gimplify_decl_expr I see there:
> if (init && init != error_mark_node)
> {
> if (!TREE_STATIC (decl))
> {
> DECL_INITIAL (decl) = NULL_TREE;
> init = build2 (INIT_EXPR, void_type_node, decl, init);
> gimplify_and_add (init, seq_p);
> ggc_free (init);
> }
> else
> /* We must still examine initializers for static variables
> as they may contain a label address. */
> walk_tree (&init, force_labels_r, NULL, NULL);
> }
> so perhaps we are usually fine.
> gimplify_compound_literal_expr doesn't clear DECL_INITIAL when
> optimizing non-addressable complit decls though (though perhaps those
> decls shouldn't appear in the IL then).
>
> > error_mark_node for autos) for TREE_READONLY && !TREE_SIDE_EFFECTS
> > decls (including autos)? Thus, why key on is_gimple_form at all?
>
> Perhaps it is not needed, I was just trying to be safe. Because
> after gimplification it will generally not be useful anyway.
If it is an initializer from constants we gimplify to a series of
assigns it might be still useful. OTOH, I'm not sure whether
a const auto is really readonly in C or if it is safe to assume
the stack part is writable and thus casting away the const and
writing to it is fine ...
I guess if you are targeting GCC 11 the safe variant is prefered,
so OK with the == PARSING check there.
Richard.
