Re: [PATCH] variable size arrays in nested functions

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

    > Basically, what's going on is that variable_size takes care of putting
    > the SAVE_EXPR on pending list, but SAVE_EXPRs can be created deeply
    > from fold (the problematic SAVE_EXPR is actually created from within 
    > build_array_type when building TREE_SIZE()). get_pending_sizes() takes
    > care of fixing up context of the SAVE_EXPRs recorded by variable_size
    > but this one slips through.

I must say that I had a lot of trouble understanding the above, but I
probably started payint attention late in this thread.

    Let us all look forward to that blessed day in which SAVE_EXPR is
    forever banished to the pit.

How could it be?  It seems to me to be semantically critical when you
need the result of expression that have side-effects.

For example, in Ada you can have an array whose array bounds are given
by function calls.  It's semantically required that those bounds be
evaluated exactly once and also when they are evaluated.  Sure, you can
use variables for the bounds, but SAVE_EXPR is just a shorthand for that
and avoids the scoping issues inherent with such variables.