On Tue, 26 Jan 2021, Jakub Jelinek wrote:
> 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?
Well, then in_gimple_form is OK as well (but note in_gimple_form
is only set from the pass manger but not unset so it could leak
== true and most definitely a 'false' is not safe either). So
yeah, the cfun based check looks safer here.
> 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
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
