On Sat, Aug 20, 2005 at 10:33:21PM -0400, Daniel Berlin wrote:
> > No. How could that possibly be?
> > We can't execute code for static
> > variable initializers, so how can we gimplify?
> What do you mean by this, exactly?
If you turn a static initializer into a code sequence, then it isn't a
static initializer. By definition, it's now a dynamic initializer.
Which would be a *serious* code quality regression.
> Because analyze_expr doesn't give us any of the info we want.
And would that be because analyze_expr isn't implemented for Ada?
> The docs for analyze_expr says:
>
> This function is responsible for lowering tree nodes not
> understood by
> generic code into understandable ones or alternatively marking
> callgraph and varpool nodes referenced by the as needed.
>
> It's the "alternatively" part that makes it useless.
Not likely in this case. The variable has to exist in order to be
marked, and in this case the whole problem is that it doesn't exist.
The Ada front end would have to create the variable at minimum, and
the it's the matter of one pointer store to produce the GENERIC form
that you want.
> cxx_callgraph_analyze_expr, an implementation of this hook, simply marks
> a bunch of varpool nodes as "used" (and it doesn't even tell us which
> ones).
>
> We don't care to know whether or not it should be marked used.
> We want to know what's actually in the trees on the initializer them so
> we can do analysis.
Sure. So far I don't see a problem though.
> IE if we have something very funky like:
>
> static int c;
> static int d;
> static struct foo *a = &{&c, &d};
>
> (and if you look, andrew found a case where we are producing
> &<constructor>, so this is a possibility, AFAICT)
I disbelieve you can get this in C or C++. The fragment above
is a syntax error. AFAIK, all of this is simple laziness in the
Ada front end: generating &<constructor> is how things were done
at the beginning of time, and it was easier to change this in the
gimplifier than to modify the code that generated this directly.
> In the above case, we need to see the &c, &d part.
> How does analyze_expr help us here?
By transforming to
static struct foo tmp = { &c, &d };
static struct foo* a = &tmp;
r~
