RE: Variable Length Arrays (VLA) proposal

["Agovic, Sanimir" <sanimir.agovic@intel.com>]

> > Breakpoint 1, test () at vla.f90:4
> > 4           ALLOCATE(vla (3, 4, 5))
> > $1 = <not allocated>
> > type = integer(kind=4), ALLOCATABLE (0:1,0:1,0:1)
> 
> This highlights another issues implementing VLA. When printing a type
> (e.g. in f-typeprint.c) you don't have the value of the variable and
> therefore you can't evaluate the DW_AT_lower_bound, DW_AT_upper_bound,
> DW_AT_allocated, etc. since they usually uses DW_OP_push_object_address
> and we don't have the value address in f_type_print and friends. So to
> print reliably print type type of an expression GDB actually needs to
> evaluate it, something it hasn't needed to do before.

Afaik gdb does a combination of:

const char * exp = [...]
struct expression *expr = parse_expression (exp);
struct value *val = evaluate_type (expr);
[...]

for whatis/ptype therefore we should be fine as we have a value in place.

 -Sanimir
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052