RE: Using the tree.

["Virgil Palanciuc" <Virgil dot Palanciuc at cs dot pub dot ro>]

> >     Yes, this looks like the explanation. But what *exactly* does 'a
> > binding level is closed' mean?
>
> A binding level is a C block:
>
> void foo(int x) /* binding level for parameters */
> {               /* a new binding level opens */
>   int i;
>   for (i=0;i<10;i++){ /* a new binding level opens */
>     int k;
>   }                   /* the binding level containing k closes */
> }               /* the binding level containing i closes */

    Thanks, but you misunderstood me (my fault :) )
    I know what 'a binding level is closed' means in terms of C language
(from the programmer's point of view), I wanted to know what it means in
terms of gcc (how this 'event' affects the data structures and so on).
However, I think you answered my question below.

> > Is the info still there (I think it should) ?
>
> I don't think so: information on local variables is lost once the
> block closes; this is the "statement at once" mode of RTL generation.
> Only in the "function at once" mode, such information is preserved to
> the end of the function.
>
> In the RTL, the variables are represented by registers, which may or
> may not be alive. I don't think you can reconstruct the declarations
> from them.

     I know I can't - I tried to, but I failed. This is why I resorted to
the tree - I tried to avoid this because I don't really know how to handle
the tree.
     Anyway, there must be a way to find out what stack slot is assigned to
each variable (and to find out this info about arrays, too !!! ).
Ultimately, this information can be obtained in the parsing step and
memorised in a different data structure until needed. This is an ugly yet
safe solution - but I don't know how (and *exactly* when) to do that,
either.

> Regards,
> Martin

       Virgil.