Re: [patch] fix wrong gimple code with ptr to forward vla

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> Your approach is imposing TYPE_DECLs on front ends.  Joseph's is 
> requiring front ends to make clear when things are evaluated.

I don't see a fundamental difference there.  Both of us are saying that there
needs to be some unambiguous way of the front end communicating to the
middle end "elaborate this type now".  I don't much care if that's done
by inserting a TYPE_DECL into the tree or some other mechanism.

> Joseph's approach is more explicit, and therefore more flexible; some 
> languages might require that array bounds be evaluated in a particular 
> order, for example, so that the equivalent of "int x[f()][g()];" had 
> well-defined behavior.  A TYPE_DECL for an ARRAY_TYPE with the obvious 
> bounds doesn't make that explicit.  

No, but whatever definition we come up with, a front end certainly can
do any needed extra evaluation in the case where it has to remove any
ambiguity, so I don't see a particularly strong argument there.

> So, the front end would need to 
> expand things anyhow; Joseph (and I) think we might as well just require 
> that the front end always do that.

My concern is that this could easily end up duplicating the gimplification
code in each front end and that's wasteful.

But there's also the concern over who does these evaluations when.  There's a
bit of a mess in the Ada front end, for example, as the Ada part of the
compiler will often make temporaries when it needs to stabilize something.
Then the C part of the Ada front end does as well and finally gimplification
does yet again.  One would hope that the optimizers would remove all of that
junk, but it would be better not to generate it in the first place.

So I would certainly support a more precise definition of exactly what has to
be stabilized when, though I'd be leery about duplicating code between the
front end and the gimplifier to do it.