On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka 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.
>
> I think it is property of function to be in generic form. We allow
> functions to be constructed late and we could allow doing that using
> generic (even though as far as I know we generate them all as gimple -
> profiling code, collected ctors, offlining etc).
>
> So perhaps we don't need to tie that with symtab state.
So do you want
(cfun && (cfun->curr_properties & PROP_trees))
instead then?
I'd really prefer such a check at least for GCC11 because while for most
automatic vars DECL_INITIAL will be cleared during gimplification, I don't
see guarantees for that and guarantees that it isn't left to be random
garbage after that.
Jakub
