Re: [PATCH] variable size arrays in nested functions

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

[I moved this to gcc@gcc.gnu.org, from the patch list.]

    Err, a VAR_DECL certainly is an expression.  I'm not suggesting that
    its _initialization_ is part of that expression.

But that's the point.

    In fact, I'll claim that the fact that the initialization of a SAVE_EXPR
    might or might not be part of the expression (being dependant on whether
    or not it has been previously evaluated) that is the source of all pain
    associated with this tree code.

No, I think it clearly *is*.

    So that a sequence of statements is needed in order to use a VAR_DECL in
    this context is in fact a feature.

Not at all!  It's a *major* pain to make that sequence of statements.
Indeed, it's so hard to find a way to handle the scoping that we don't
support variable-sized temporaries.

Let's look at a typical use of SAVE_EXPR.  Suppose we have a language
where index bounds are checked (e.g., Ada) and you have an expression
of the form (in C syntax)

	... (expression1 && X[expression2]) ...

and suppose both expressions have side effects.

To do the range check, you basically generate the RHS of the && as if
it were

	X[((expression2 >= LB && expression2 <= UB ? expression2 : abort ()]

But each of those "expression2"s are a SAVE_EXPR since (with the assumption
of side effects) we can only evaluate it once.

What are you proposing to do, as I understand it, is to create some
(unnamed) variable, which we'll call UV for clarity and use it instead
of "expression2".  Where do you propose putting the statement to
initialize it?  I suppose before the statement containing the
expression.  But you can't since expression2 must not be evaluated if
expression1 is true. So you have to do something peculiar, like
perhaps an expression statement.  But if you do that haven't you
created something with the same semantic problems as SAVE_EXPR,
whatever they are, except thaht now it's much more complicated?

And now you lose optimization.  In the case where these are size or offsets,
usually knowing what the "initializing value", in your model, is will
allow significant optimizations.

    To work around problems encountered with evaluating SAVE_EXPRs.
    I won't pretend to know exactly which ones, or why UNSAVE_EXPR
    was thought to be a "solution".

Well, unless we can state the problems, why talk about eliminating
them in a way that will cause yet more serious problems (and not
really solve them since it's the same semantic issue)?

I'm not aware of any problems in the GCC context or even in the Ada context
(where SAVE_EXPRs are used *far, far* more than in C and probably even C++).