This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Variable Length Arrays (VLA) proposal
- From: Chris January <chris dot january at allinea dot com>
- To: "Agovic, Sanimir" <sanimir dot agovic at intel dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>, "Boell, Keven" <keven dot boell at intel dot com>, "Weinmann, Christoph T" <christoph dot t dot weinmann at intel dot com>
- Date: Thu, 04 Jul 2013 10:13:25 +0100
- Subject: RE: Variable Length Arrays (VLA) proposal
- References: <0377C58828D86C4588AEEC42FC3B85A7176288F9 at IRSMSX105 dot ger dot corp dot intel dot com> <1372434039 dot 2950 dot 12 dot camel at gumtree> <0377C58828D86C4588AEEC42FC3B85A71762A7F2 at IRSMSX105 dot ger dot corp dot intel dot com>
On Thu, 2013-07-04 at 08:17 +0000, Agovic, Sanimir wrote:
> $ nl vla.f90
> 1 PROGRAM test
> 2 INTEGER, ALLOCATABLE :: vla(:, :, :)
> 3 CHARACTER(len=:), ALLOCATABLE :: str
> 4 ALLOCATE(vla (3, 4, 5))
> 5 ALLOCATE(character(len=2) :: str)
> 6 vla(:,:,:) = 42
> 7 str = '42'
> 8 call EXIT(0)
> 9 END PROGRAM test
> 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.
Regards,
Chris