> And would that be because analyze_expr isn't implemented for Ada?
That doesn't bother me so much, actually (mainly because i don't care
about Ada). It's the fact that it's popping up in C/C++ that does.
>
> > 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++.
That's how this whole discussion popped up originally.
Andrew discovered an equivalent C/C++ testcase that produces
&<CONSTRUCTOR>.
See PR 23171.
Since C/C++'s analyze_expr (or whatever you want to produce that code)
doesn't produce the nice code below for that testcase, we get screwed.
> 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;
By "gimplify static initializers", i actually meant produce the code
you've listed from whatever was generating &<constructor>. Nothing
more.
If analyze_expr (or something) actually did that, i'd be a very happy
man.
It doesn't, unfortunately.
Another perfectly reasonable solution would be to force us to not
generate such crap in the first place.
