Bootstrap failure on powerpc-apple-darwin8 with Ada

[Daniel Berlin]

> 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.