public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* Re: [V4 00/21] Fortran dynamic array support
       [not found]                 ` <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com>
@ 2016-08-16 13:59                   ` Jan Kratochvil
  2016-08-19  9:58                     ` Bernhard Heckel
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-08-16 13:59 UTC (permalink / raw)
  To: Heckel, Bernhard; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 3530 bytes --]

Hi Bernhard,

On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote:
> I took a look at "p varw" issue.
> 
> >From my point of view, the debug information for  the location of varw is wrong. 
> 
> Set a breakpoint at line 68 and run.
> "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase.
> Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation
> of "varw" is correct. From my point of view, the location expression of "varw" is wrong.
> 
> If you manual examine the content at "loc(varw)" you see the right content.
> 
> FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation. 
> 
> I attached the testcase + dwarf

primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel
VLA patch series - does PASS the testcase fine with gfortran DWARF so
completely wrong the DWARF is not.

Also you talk here only about starting address of 'varw'.  But that is not
a problem, the starting address in inferior + in GDB do match:
  varw(1, 1, 1) = 6
vs.
$23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) )
(gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled
 - the value 6 is really the first (1,1,1) value printed.
The starting address is nothing special for GDB as starting address is
adjusted/offseted by the inferior caller, GDB just reads the inferior-computed
address.

What is wrong is accessing 'varw' elements not in the first row of the array
by GDB - because GDB needs to know the stride for it.
Stride is described there in DWARF:
    <231>   DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22   (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus)
    <23d>   DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e  (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
and that just fetches the values from gfortran array descriptor - otherwise the
inferior Fortran function 'foo' would not work.

Why do you think gfortran has the DWARF wrong?  Do your GDB patches PASS with
ifort?  I no longer have ifort - I got a license from Markus Metzger many
years ago, it was somehow complicated in Intel to get it for me and the
license laster only one year.  You would have to send me the ifort-built
binary (or .s file).


I have tried now to re-apply a part of the old working Intel VLA patch of
value_subscripted_rvalue():
   unsigned int elt_size = TYPE_LENGTH (elt_type);
-  unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
+  unsigned int elt_offs = longest_to_int (index - lowerbound);
+  LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type));
   struct value *v;

+  if (elt_stride > 0)
+    elt_offs *= elt_stride;
+  else if (elt_stride < 0)
+    {
+      int offs = (elt_offs + 1) * elt_stride;
+
+      elt_offs = TYPE_LENGTH (array_type) + offs;
+    }
+  else
+    elt_offs *= elt_size;
+

But it does not work (attached).  Maybe because the stride of an array now
appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type)
while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE
for that.


Thanks,
Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 2181 bytes --]

--- ./gdb/valarith.c	2016-08-16 15:36:10.680313175 +0200
+++ ./gdb/valarith.c	2016-08-16 15:33:18.696930843 +0200
@@ -193,9 +193,22 @@ value_subscripted_rvalue (struct value *
   struct type *array_type = check_typedef (value_type (array));
   struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type));
   ULONGEST elt_size = type_length_units (elt_type);
-  ULONGEST elt_offs = elt_size * (index - lowerbound);
+  ULONGEST elt_offs = index - lowerbound;
+  LONGEST elt_stride = TYPE_FIELD_BITSIZE (array_type, 0);
   struct value *v;
 
+if (elt_stride) fprintf(stderr,"value_subscripted_rvalue: elt_stride=%ld\n",elt_stride);
+  if (elt_stride > 0)
+    elt_offs *= elt_stride;
+  else if (elt_stride < 0)
+    {
+      int offs = (elt_offs + 1) * elt_stride;
+
+      elt_offs = TYPE_LENGTH (array_type) + offs;
+    }
+  else
+    elt_offs *= elt_size;
+
   if (index < lowerbound || (!TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED (array_type)
 			     && elt_offs >= type_length_units (array_type)))
     {
--- ./gdb/valops.c	2016-08-16 15:36:10.694313288 +0200
+++ ./gdb/valops.c	2016-08-16 15:04:54.963343948 +0200
@@ -3826,7 +3826,7 @@ value_slice_1 (struct value *array, int
   struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type));
   unsigned int elt_size, elt_offs;
   /* ATTRIBUTE_UNUSED: VLA bug: https://sourceware.org/ml/gdb-patches/2016-08/msg00099.html */
-  LONGEST elt_stride ATTRIBUTE_UNUSED, ary_high_bound, ary_low_bound;
+  LONGEST elt_stride, ary_high_bound, ary_low_bound;
   struct value *v;
   int slice_range_size, i = 0, row_count = 1, elem_count = 1;
 
@@ -3863,7 +3863,17 @@ value_slice_1 (struct value *array, int
   elt_offs = lowbound - ary_low_bound;
   elt_stride = TYPE_LENGTH (TYPE_INDEX_TYPE (array_type));
 
-  elt_offs *= elt_size;
+fprintf(stderr,"elt_stride=%d\n",elt_stride);
+  if (elt_stride > 0)
+    elt_offs *= elt_stride;
+  else if (elt_stride < 0)
+    {
+      int offs = (elt_offs + 1) * elt_stride;
+
+      elt_offs = TYPE_LENGTH (array_type) + offs;
+    }
+  else
+    elt_offs *= elt_size;
 
   /* Check for valid user input.  In case of Fortran this was already done
      in the calling function.  */

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-16 13:59                   ` [V4 00/21] Fortran dynamic array support Jan Kratochvil
@ 2016-08-19  9:58                     ` Bernhard Heckel
  2016-08-21 17:04                       ` Jan Kratochvil
  0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Heckel @ 2016-08-19  9:58 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 16/08/2016 15:59, Jan Kratochvil wrote:
> Hi Bernhard,
>
> On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote:
>> I took a look at "p varw" issue.
>>
>> >From my point of view, the debug information for  the location of varw is wrong.
>>
>> Set a breakpoint at line 68 and run.
>> "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase.
>> Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation
>> of "varw" is correct. From my point of view, the location expression of "varw" is wrong.
>>
>> If you manual examine the content at "loc(varw)" you see the right content.
>>
>> FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation.
>>
>> I attached the testcase + dwarf
> primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel
> VLA patch series - does PASS the testcase fine with gfortran DWARF so
> completely wrong the DWARF is not.
>
> Also you talk here only about starting address of 'varw'.  But that is not
> a problem, the starting address in inferior + in GDB do match:
>    varw(1, 1, 1) = 6
> vs.
> $23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) )
> (gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled
>   - the value 6 is really the first (1,1,1) value printed.
> The starting address is nothing special for GDB as starting address is
> adjusted/offseted by the inferior caller, GDB just reads the inferior-computed
> address.
>
> What is wrong is accessing 'varw' elements not in the first row of the array
> by GDB - because GDB needs to know the stride for it.
> Stride is described there in DWARF:
>      <231>   DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22   (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus)
>      <23d>   DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e  (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
> and that just fetches the values from gfortran array descriptor - otherwise the
> inferior Fortran function 'foo' would not work.
>
> Why do you think gfortran has the DWARF wrong?  Do your GDB patches PASS with
> ifort?  I no longer have ifort - I got a license from Markus Metzger many
> years ago, it was somehow complicated in Intel to get it for me and the
> license laster only one year.  You would have to send me the ifort-built
> binary (or .s file).
>
>
> I have tried now to re-apply a part of the old working Intel VLA patch of
> value_subscripted_rvalue():
>     unsigned int elt_size = TYPE_LENGTH (elt_type);
> -  unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
> +  unsigned int elt_offs = longest_to_int (index - lowerbound);
> +  LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type));
>     struct value *v;
>
> +  if (elt_stride > 0)
> +    elt_offs *= elt_stride;
> +  else if (elt_stride < 0)
> +    {
> +      int offs = (elt_offs + 1) * elt_stride;
> +
> +      elt_offs = TYPE_LENGTH (array_type) + offs;
> +    }
> +  else
> +    elt_offs *= elt_size;
> +
>
> But it does not work (attached).  Maybe because the stride of an array now
> appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type)
> while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE
> for that.
>
>
> Thanks,
> Jan
Hi Jan,

here is the missing patch in your environment.
https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html
This patch handles strides in DWARF and your fortran program.

Christoph's patch series was about strides in user input, for example 
"print my_vla(1:10:2)"

I will create a branch about all stride patches in the next weeks.



Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-19  9:58                     ` Bernhard Heckel
@ 2016-08-21 17:04                       ` Jan Kratochvil
  2016-08-23 13:34                         ` Bernhard Heckel
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-08-21 17:04 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

On Fri, 19 Aug 2016 11:58:09 +0200, Bernhard Heckel wrote:
> here is the missing patch in your environment.
> https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html
> This patch handles strides in DWARF and your fortran program.

OK, thanks, it does fix:
	-FAIL: gdb.fortran/dynamic.exp: p varw filled
	+PASS: gdb.fortran/dynamic.exp: p varw filled
	-FAIL: gdb.fortran/vla-stride.exp: print odd-elements
	+PASS: gdb.fortran/vla-stride.exp: print odd-elements
	-FAIL: gdb.fortran/vla-stride.exp: print last odd-element
	+PASS: gdb.fortran/vla-stride.exp: print last odd-element

Although it regresses:
	 print pvla^M
	-$7 = (5)^M
	-(gdb) PASS: gdb.fortran/vla-stride.exp: print single-element
	+value requires 4294967288 bytes, which is more than max-value-size^M
	+(gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element
	-$8 = 5^M
	-(gdb) PASS: gdb.fortran/vla-stride.exp: print one single-element
	+Insufficient memory in host GDB for object of size 4294967288 bytes, maximum allowed 536870911 bytes.^M
	+(gdb) FAIL: gdb.fortran/vla-stride.exp: print one single-element


> I will create a branch about all stride patches in the next weeks.

That would be probably best, thanks.


Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-21 17:04                       ` Jan Kratochvil
@ 2016-08-23 13:34                         ` Bernhard Heckel
  2016-08-25 17:06                           ` Jan Kratochvil
  2016-09-01  9:48                           ` Jan Kratochvil
  0 siblings, 2 replies; 26+ messages in thread
From: Bernhard Heckel @ 2016-08-23 13:34 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 21/08/2016 19:03, Jan Kratochvil wrote:
> On Fri, 19 Aug 2016 11:58:09 +0200, Bernhard Heckel wrote:
>> here is the missing patch in your environment.
>> https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html
>> This patch handles strides in DWARF and your fortran program.
> OK, thanks, it does fix:
> 	-FAIL: gdb.fortran/dynamic.exp: p varw filled
> 	+PASS: gdb.fortran/dynamic.exp: p varw filled
> 	-FAIL: gdb.fortran/vla-stride.exp: print odd-elements
> 	+PASS: gdb.fortran/vla-stride.exp: print odd-elements
> 	-FAIL: gdb.fortran/vla-stride.exp: print last odd-element
> 	+PASS: gdb.fortran/vla-stride.exp: print last odd-element
>
> Although it regresses:
> 	 print pvla^M
> 	-$7 = (5)^M
> 	-(gdb) PASS: gdb.fortran/vla-stride.exp: print single-element
> 	+value requires 4294967288 bytes, which is more than max-value-size^M
> 	+(gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element
> 	-$8 = 5^M
> 	-(gdb) PASS: gdb.fortran/vla-stride.exp: print one single-element
> 	+Insufficient memory in host GDB for object of size 4294967288 bytes, maximum allowed 536870911 bytes.^M
> 	+(gdb) FAIL: gdb.fortran/vla-stride.exp: print one single-element
>
>
>> I will create a branch about all stride patches in the next weeks.
> That would be probably best, thanks.
>
>
> Jan
Hi Jan,

created a branch with all stride patches.
I don't see regression on RH7.1, gcc 4.8.3-9


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-23 13:34                         ` Bernhard Heckel
@ 2016-08-25 17:06                           ` Jan Kratochvil
  2016-08-25 17:22                             ` Jan Kratochvil
  2016-09-02 13:44                             ` Bernhard Heckel
  2016-09-01  9:48                           ` Jan Kratochvil
  1 sibling, 2 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-08-25 17:06 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote:
> created a branch with all stride patches.

users/bheckel/fortran-strides
2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b

> I don't see regression on RH7.1, gcc 4.8.3-9

I see a regression for 32-bit targets (x86_64-m32 or native i686)
on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64).  I do not see the regression
on CentOS-7.2 (x86_64-m32).

print pvla^M
value requires 4294967288 bytes, which is more than max-value-size^M
(gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element

I have attached a fix.

It is because:
    <115>   DW_AT_lower_bound : 4 byte block: 97 23 10 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 16; DW_OP_deref)
    <11a>   DW_AT_upper_bound : 4 byte block: 97 23 14 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 20; DW_OP_deref)
    <11f>   DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e   (DW_OP_push_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
	DW_AT_lower_bound == 1
	DW_AT_upper_bound == 1
	DW_AT_byte_stride == (-2) * 4 == -8

I am not sure if gfortran is really wrong or not but a stride does not make
sense for me for a single row array.

Attaching also gdb.fortran/vla-stride.f90 from your branch built with
gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode.

Besides that I see on all archs
	-FAIL: gdb.pascal/arrays.exp: Print dynamic array of string
	+FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB internal error)
but that testcase is only in Fedora and the Pascal (fpc) support has been not
well maintained so far so I am OK with that.


Thanks,
Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 797 bytes --]

diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 88801ac..1fbf69a 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -1103,10 +1103,12 @@ create_array_type_with_stride (struct type *result_type,
       if (high_bound < low_bound)
 	TYPE_LENGTH (result_type) = 0;
       else if (byte_stride > 0)
-	TYPE_LENGTH (result_type) = byte_stride * (high_bound - low_bound + 1);
+	TYPE_LENGTH (result_type) = (byte_stride * (high_bound - low_bound)
+				     + TYPE_LENGTH (element_type));
       else if (bit_stride > 0)
 	TYPE_LENGTH (result_type) =
-	  (bit_stride * (high_bound - low_bound + 1) + 7) / 8;
+	  ((bit_stride * (high_bound - low_bound) + 7) / 8
+	   + TYPE_LENGTH (element_type));
       else
 	TYPE_LENGTH (result_type) =
 	  TYPE_LENGTH (element_type) * (high_bound - low_bound + 1);

[-- Attachment #3: vla-stride.s --]
[-- Type: text/plain, Size: 21421 bytes --]

	.file	"vla-stride.f90"
	.text
.Ltext0:
	.section	.rodata
	.align 4
.LC0:
	.string	"Integer overflow when calculating the amount of memory to allocate"
.LC1:
	.string	"vla"
	.align 4
.LC2:
	.string	"Attempting to allocate already allocated variable '%s'"
	.align 4
.LC3:
	.string	"At line 20 of file gdb.fortran/vla-stride.f90"
	.align 4
.LC4:
	.string	"Allocation would exceed memory limit"
	.text
	.type	MAIN__, @function
MAIN__:
.LFB0:
	.file 1 "gdb.fortran/vla-stride.f90"
	# gdb.fortran/vla-stride.f90:16
	.loc 1 16 0
	.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (FALLTHRU)
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$60, %esp
	.cfi_offset 7, -12
	.cfi_offset 6, -16
	.cfi_offset 3, -20
	# gdb.fortran/vla-stride.f90:17
	.loc 1 17 0
	movl	$0, -72(%ebp)
.LBB2:
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0
	movl	$0, %eax
	testl	%eax, %eax
# SUCC: 3 (FALLTHRU) 4
	je	.L2
# BLOCK 3 seq:1
# PRED: 2 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 is_stmt 0 discriminator 1
	subl	$12, %esp
	pushl	$.LC0
# SUCC:
	call	_gfortran_runtime_error
# BLOCK 4 seq:2
# PRED: 2
.L2:
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 discriminator 2
	movl	-72(%ebp), %eax
	testl	%eax, %eax
# SUCC: 5 (FALLTHRU) 6
	je	.L3
# BLOCK 5 seq:3
# PRED: 4 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 discriminator 3
	subl	$4, %esp
	pushl	$.LC1
	pushl	$.LC2
	pushl	$.LC3
# SUCC:
	call	_gfortran_runtime_error_at
# BLOCK 6 seq:4
# PRED: 4
.L3:
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 discriminator 4
	subl	$12, %esp
	pushl	$40
	call	malloc
	addl	$16, %esp
	movl	%eax, -72(%ebp)
	movl	-72(%ebp), %eax
	testl	%eax, %eax
# SUCC: 7 (FALLTHRU) 8
	jne	.L4
# BLOCK 7 seq:5
# PRED: 6 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 discriminator 5
	subl	$12, %esp
	pushl	$.LC4
# SUCC:
	call	_gfortran_os_error
# BLOCK 8 seq:6
# PRED: 6
.L4:
	# gdb.fortran/vla-stride.f90:20
	.loc 1 20 0 discriminator 6
	movl	$265, -64(%ebp)
	movl	$1, -56(%ebp)
	movl	$10, -52(%ebp)
	movl	$1, -60(%ebp)
	movl	$-1, -68(%ebp)
.LBB3:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 is_stmt 1 discriminator 6
	movl	-72(%ebp), %edx
	movl	-68(%ebp), %esi
	movl	-56(%ebp), %ebx
.LBB4:
.LBB5:
	movl	-72(%ebp), %eax
	testl	%eax, %eax
	sete	%al
	movzbl	%al, %eax
	testl	%eax, %eax
# SUCC: 10 9 (FALLTHRU)
	jne	.L5
# BLOCK 9 seq:7
# PRED: 8 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 is_stmt 0 discriminator 2
	movl	-56(%ebp), %ecx
	leal	9(%ecx), %edi
	movl	-52(%ebp), %ecx
	cmpl	%ecx, %edi
# SUCC: 10 (FALLTHRU) 18
	je	.L6
# BLOCK 10 seq:8
# PRED: 8 9 (FALLTHRU)
.L5:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 3
	testl	%eax, %eax
# SUCC: 11 (FALLTHRU) 12
	je	.L7
# BLOCK 11 seq:9
# PRED: 10 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 4
	movl	$0, %eax
# SUCC: 13 [100.0%] 
	jmp	.L8
# BLOCK 12 seq:10
# PRED: 10
.L7:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 5
	movl	-52(%ebp), %edx
	movl	-56(%ebp), %eax
	subl	%eax, %edx
	movl	%edx, %eax
	addl	$1, %eax
	movl	$0, %edx
	testl	%eax, %eax
# SUCC: 13 (FALLTHRU)
	cmovs	%edx, %eax
# BLOCK 13 seq:11
# PRED: 12 (FALLTHRU) 11 [100.0%] 
.L8:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 7
	cmpl	$10, %eax
	setne	%al
	movzbl	%al, %eax
	movl	$1, -56(%ebp)
	movl	$10, -52(%ebp)
	movl	$1, -60(%ebp)
	movl	-56(%ebp), %edx
	negl	%edx
	movl	%edx, -68(%ebp)
	movl	-68(%ebp), %esi
	movl	-56(%ebp), %ebx
	movl	-72(%ebp), %edx
	testl	%edx, %edx
# SUCC: 14 (FALLTHRU) 15
	jne	.L9
# BLOCK 14 seq:12
# PRED: 13 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 8
	subl	$12, %esp
	pushl	$40
	call	malloc
	addl	$16, %esp
	movl	%eax, -72(%ebp)
	movl	$265, -64(%ebp)
# SUCC: 17 [100.0%] 
	jmp	.L10
# BLOCK 15 seq:13
# PRED: 13
.L9:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 9
	testl	%eax, %eax
# SUCC: 16 (FALLTHRU) 17
	je	.L10
# BLOCK 16 seq:14
# PRED: 15 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 11
	movl	-72(%ebp), %eax
	subl	$8, %esp
	pushl	$40
	pushl	%eax
	call	realloc
	addl	$16, %esp
# SUCC: 17 (FALLTHRU)
	movl	%eax, -72(%ebp)
# BLOCK 17 seq:15
# PRED: 16 (FALLTHRU) 15 14 [100.0%] 
.L10:
# SUCC: 18 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 13
	movl	-72(%ebp), %edx
# BLOCK 18 seq:16
# PRED: 9 17 (FALLTHRU)
.L6:
.LBE5:
# SUCC: 19 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 14
	movl	$0, %eax
# BLOCK 19 seq:17
# PRED: 18 (FALLTHRU) 20 [100.0%] 
.L12:
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 17
	cmpl	$9, %eax
# SUCC: 21 20 (FALLTHRU)
	jg	.L11
# BLOCK 20 seq:18
# PRED: 19 (FALLTHRU)
	# gdb.fortran/vla-stride.f90:21
	.loc 1 21 0 discriminator 16
	leal	(%eax,%ebx), %ecx
	leal	(%ecx,%esi), %edi
	movl	A.1.3368(,%eax,4), %ecx
	movl	%ecx, (%edx,%edi,4)
	addl	$1, %eax
# SUCC: 19 [100.0%] 
	jmp	.L12
# BLOCK 21 seq:19
# PRED: 19
.L11:
.LBE4:
.LBE3:
	# gdb.fortran/vla-stride.f90:23
	.loc 1 23 0 is_stmt 1
	movl	$265, -40(%ebp)
	movl	$1, -32(%ebp)
	movl	$10, -28(%ebp)
	movl	$-1, -36(%ebp)
	movl	-72(%ebp), %eax
	movl	-56(%ebp), %edx
	movl	$10, %ecx
	subl	%edx, %ecx
	movl	%ecx, %edx
	sall	$2, %edx
	addl	%edx, %eax
	movl	%eax, -48(%ebp)
	movl	$1, -44(%ebp)
.LBB6:
	# gdb.fortran/vla-stride.f90:24
	.loc 1 24 0
	movl	$265, -40(%ebp)
	movl	-36(%ebp), %eax
	movl	$1, -32(%ebp)
	movl	$10, -28(%ebp)
	movl	%eax, %edx
	negl	%edx
	movl	%edx, -36(%ebp)
	movl	-48(%ebp), %edx
	movl	-32(%ebp), %ecx
	movl	$10, %ebx
	subl	%ecx, %ebx
	movl	%ebx, %ecx
	imull	%eax, %ecx
	sall	$2, %ecx
	addl	%ecx, %edx
	movl	%edx, -48(%ebp)
	movl	%eax, -44(%ebp)
.LBE6:
	# gdb.fortran/vla-stride.f90:25
	.loc 1 25 0
	movl	$265, -40(%ebp)
	movl	$1, -32(%ebp)
	movl	$5, -28(%ebp)
	movl	$2, -36(%ebp)
	movl	-72(%ebp), %eax
	movl	-56(%ebp), %edx
	movl	$1, %ecx
	subl	%edx, %ecx
	movl	%ecx, %edx
	sall	$2, %edx
	addl	%edx, %eax
	movl	%eax, -48(%ebp)
	movl	$-2, -44(%ebp)
	# gdb.fortran/vla-stride.f90:26
	.loc 1 26 0
	movl	$265, -40(%ebp)
	movl	$1, -32(%ebp)
	movl	$1, -28(%ebp)
	movl	$-2, -36(%ebp)
	movl	-72(%ebp), %eax
	movl	-56(%ebp), %edx
	movl	$5, %ecx
	subl	%edx, %ecx
	movl	%ecx, %edx
	sall	$2, %edx
	addl	%edx, %eax
	movl	%eax, -48(%ebp)
	movl	$2, -44(%ebp)
	# gdb.fortran/vla-stride.f90:28
	.loc 1 28 0
	movl	$0, -48(%ebp)
.LBE2:
	# gdb.fortran/vla-stride.f90:29
	.loc 1 29 0
	nop
	leal	-12(%ebp), %esp
	popl	%ebx
	.cfi_restore 3
	popl	%esi
	.cfi_restore 6
	popl	%edi
	.cfi_restore 7
	popl	%ebp
	.cfi_restore 5
	.cfi_def_cfa 4, 4
# SUCC: EXIT [100.0%] 
	ret
	.cfi_endproc
.LFE0:
	.size	MAIN__, .-MAIN__
	.globl	main
	.type	main, @function
main:
.LFB1:
	# gdb.fortran/vla-stride.f90:29
	.loc 1 29 0
	.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (FALLTHRU)
	leal	4(%esp), %ecx
	.cfi_def_cfa 1, 0
	andl	$-16, %esp
	pushl	-4(%ecx)
	pushl	%ebp
	.cfi_escape 0x10,0x5,0x2,0x75,0
	movl	%esp, %ebp
	pushl	%ecx
	.cfi_escape 0xf,0x3,0x75,0x7c,0x6
	subl	$4, %esp
	movl	%ecx, %eax
	# gdb.fortran/vla-stride.f90:29
	.loc 1 29 0
	subl	$8, %esp
	pushl	4(%eax)
	pushl	(%eax)
	call	_gfortran_set_args
	addl	$16, %esp
	subl	$8, %esp
	pushl	$options.3.3382
	pushl	$9
	call	_gfortran_set_options
	addl	$16, %esp
	call	MAIN__
	movl	$0, %eax
	movl	-4(%ebp), %ecx
	.cfi_def_cfa 1, 0
	leave
	.cfi_restore 5
	leal	-4(%ecx), %esp
	.cfi_def_cfa 4, 4
# SUCC: EXIT [100.0%] 
	ret
	.cfi_endproc
.LFE1:
	.size	main, .-main
	.section	.rodata
	.align 32
	.type	A.1.3368, @object
	.size	A.1.3368, 40
A.1.3368:
	.long	1
	.long	2
	.long	3
	.long	4
	.long	5
	.long	6
	.long	7
	.long	8
	.long	9
	.long	10
	.align 32
	.type	options.3.3382, @object
	.size	options.3.3382, 36
options.3.3382:
	.long	68
	.long	1023
	.long	0
	.long	0
	.long	1
	.long	1
	.long	0
	.long	0
	.long	31
	.text
.Letext0:
	.section	.debug_info,"",@progbits
.Ldebug_info0:
	.long	0x128	# Length of Compilation Unit Info
	.value	0x4	# DWARF version number
	.long	.Ldebug_abbrev0	# Offset Into Abbrev. Section
	.byte	0x4	# Pointer Size (in bytes)
	.uleb128 0x1	# (DIE (0xb) DW_TAG_compile_unit)
	.long	.LASF5	# DW_AT_producer: "GNU Fortran2008 6.1.1 20160621 (Red Hat 6.1.1-3) -m32 -mtune=generic -march=i686 -g -fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/finclude"
	.byte	0xe	# DW_AT_language
	.byte	0x2	# DW_AT_identifier_case
	.long	.LASF6	# DW_AT_name: "gdb.fortran/vla-stride.f90"
	.long	.LASF7	# DW_AT_comp_dir: "/home/jkratoch/redhat/gdb-clean/gdb/testsuite"
	.long	.Ltext0	# DW_AT_low_pc
	.long	.Letext0-.Ltext0	# DW_AT_high_pc
	.long	.Ldebug_line0	# DW_AT_stmt_list
	.uleb128 0x2	# (DIE (0x26) DW_TAG_base_type)
	.byte	0x4	# DW_AT_byte_size
	.byte	0x5	# DW_AT_encoding
	.long	.LASF2	# DW_AT_name: "integer(kind=4)"
	.uleb128 0x3	# (DIE (0x2d) DW_TAG_const_type)
	.long	0x26	# DW_AT_type
	.uleb128 0x4	# (DIE (0x32) DW_TAG_subprogram)
			# DW_AT_external
	.long	.LASF8	# DW_AT_name: "main"
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x1d	# DW_AT_decl_line
	.long	0x26	# DW_AT_type
	.long	.LFB1	# DW_AT_low_pc
	.long	.LFE1-.LFB1	# DW_AT_high_pc
	.uleb128 0x1	# DW_AT_frame_base
	.byte	0x9c	# DW_OP_call_frame_cfa
			# DW_AT_GNU_all_tail_call_sites
	.long	0x69	# DW_AT_sibling
	.uleb128 0x5	# (DIE (0x4b) DW_TAG_formal_parameter)
	.long	.LASF0	# DW_AT_name: "argc"
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x1d	# DW_AT_decl_line
	.long	0x2d	# DW_AT_type
	.uleb128 0x2	# DW_AT_location
	.byte	0x91	# DW_OP_fbreg
	.sleb128 0
	.uleb128 0x5	# (DIE (0x59) DW_TAG_formal_parameter)
	.long	.LASF1	# DW_AT_name: "argv"
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x1d	# DW_AT_decl_line
	.long	0x69	# DW_AT_type
	.uleb128 0x3	# DW_AT_location
	.byte	0x91	# DW_OP_fbreg
	.sleb128 4
	.byte	0x6	# DW_OP_deref
	.byte	0	# end of children of DIE 0x32
	.uleb128 0x6	# (DIE (0x69) DW_TAG_pointer_type)
	.byte	0x4	# DW_AT_byte_size
	.long	0x6f	# DW_AT_type
	.uleb128 0x2	# (DIE (0x6f) DW_TAG_base_type)
	.byte	0x1	# DW_AT_byte_size
	.byte	0x8	# DW_AT_encoding
	.long	.LASF3	# DW_AT_name: "character(kind=1)"
	.uleb128 0x7	# (DIE (0x76) DW_TAG_subprogram)
	.long	.LASF9	# DW_AT_name: "vla_stride"
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x10	# DW_AT_decl_line
			# DW_AT_main_subprogram
	.byte	0x2	# DW_AT_calling_convention
	.long	.LFB0	# DW_AT_low_pc
	.long	.LFE0-.LFB0	# DW_AT_high_pc
	.uleb128 0x1	# DW_AT_frame_base
	.byte	0x9c	# DW_OP_call_frame_cfa
			# DW_AT_GNU_all_tail_call_sites
	.long	0xe7	# DW_AT_sibling
	.uleb128 0x8	# (DIE (0x8c) DW_TAG_variable)
	.ascii "i\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x15	# DW_AT_decl_line
	.long	0x26	# DW_AT_type
	.uleb128 0x9	# (DIE (0x95) DW_TAG_variable)
	.long	.LASF4	# DW_AT_name: "pvla"
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x12	# DW_AT_decl_line
	.long	0xe7	# DW_AT_type
	.uleb128 0x2	# DW_AT_location
	.byte	0x91	# DW_OP_fbreg
	.sleb128 -56
	.uleb128 0xa	# (DIE (0xa3) DW_TAG_variable)
	.ascii "vla\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file (gdb.fortran/vla-stride.f90)
	.byte	0x11	# DW_AT_decl_line
	.long	0x10b	# DW_AT_type
	.uleb128 0x3	# DW_AT_location
	.byte	0x91	# DW_OP_fbreg
	.sleb128 -80
	.uleb128 0xb	# (DIE (0xb2) DW_TAG_lexical_block)
	.long	.LBB2	# DW_AT_low_pc
	.long	.LBE2-.LBB2	# DW_AT_high_pc
	.uleb128 0xc	# (DIE (0xbb) DW_TAG_lexical_block)
	.long	.LBB3	# DW_AT_low_pc
	.long	.LBE3-.LBB3	# DW_AT_high_pc
	.long	0xdc	# DW_AT_sibling
	.uleb128 0xb	# (DIE (0xc8) DW_TAG_lexical_block)
	.long	.LBB4	# DW_AT_low_pc
	.long	.LBE4-.LBB4	# DW_AT_high_pc
	.uleb128 0xd	# (DIE (0xd1) DW_TAG_lexical_block)
	.long	.LBB5	# DW_AT_low_pc
	.long	.LBE5-.LBB5	# DW_AT_high_pc
	.byte	0	# end of children of DIE 0xc8
	.byte	0	# end of children of DIE 0xbb
	.uleb128 0xd	# (DIE (0xdc) DW_TAG_lexical_block)
	.long	.LBB6	# DW_AT_low_pc
	.long	.LBE6-.LBB6	# DW_AT_high_pc
	.byte	0	# end of children of DIE 0xb2
	.byte	0	# end of children of DIE 0x76
	.uleb128 0xe	# (DIE (0xe7) DW_TAG_array_type)
	.uleb128 0x2	# DW_AT_data_location
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x6	# DW_OP_deref
	.uleb128 0x4	# DW_AT_associated
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x6	# DW_OP_deref
	.byte	0x30	# DW_OP_lit0
	.byte	0x2e	# DW_OP_ne
	.long	0x26	# DW_AT_type
	.long	0x10b	# DW_AT_sibling
	.uleb128 0xf	# (DIE (0xf8) DW_TAG_subrange_type)
	.uleb128 0x4	# DW_AT_lower_bound
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x10
	.byte	0x6	# DW_OP_deref
	.uleb128 0x4	# DW_AT_upper_bound
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x14
	.byte	0x6	# DW_OP_deref
	.uleb128 0x6	# DW_AT_byte_stride
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0xc
	.byte	0x6	# DW_OP_deref
	.byte	0x34	# DW_OP_lit4
	.byte	0x1e	# DW_OP_mul
	.byte	0	# end of children of DIE 0xe7
	.uleb128 0x10	# (DIE (0x10b) DW_TAG_array_type)
	.uleb128 0x2	# DW_AT_data_location
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x6	# DW_OP_deref
	.uleb128 0x4	# DW_AT_allocated
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x6	# DW_OP_deref
	.byte	0x30	# DW_OP_lit0
	.byte	0x2e	# DW_OP_ne
	.long	0x26	# DW_AT_type
	.uleb128 0xf	# (DIE (0x118) DW_TAG_subrange_type)
	.uleb128 0x4	# DW_AT_lower_bound
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x10
	.byte	0x6	# DW_OP_deref
	.uleb128 0x4	# DW_AT_upper_bound
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0x14
	.byte	0x6	# DW_OP_deref
	.uleb128 0x6	# DW_AT_byte_stride
	.byte	0x97	# DW_OP_push_object_address
	.byte	0x23	# DW_OP_plus_uconst
	.uleb128 0xc
	.byte	0x6	# DW_OP_deref
	.byte	0x34	# DW_OP_lit4
	.byte	0x1e	# DW_OP_mul
	.byte	0	# end of children of DIE 0x10b
	.byte	0	# end of children of DIE 0xb
	.section	.debug_abbrev,"",@progbits
.Ldebug_abbrev0:
	.uleb128 0x1	# (abbrev code)
	.uleb128 0x11	# (TAG: DW_TAG_compile_unit)
	.byte	0x1	# DW_children_yes
	.uleb128 0x25	# (DW_AT_producer)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x13	# (DW_AT_language)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x42	# (DW_AT_identifier_case)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x1b	# (DW_AT_comp_dir)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.uleb128 0x10	# (DW_AT_stmt_list)
	.uleb128 0x17	# (DW_FORM_sec_offset)
	.byte	0
	.byte	0
	.uleb128 0x2	# (abbrev code)
	.uleb128 0x24	# (TAG: DW_TAG_base_type)
	.byte	0	# DW_children_no
	.uleb128 0xb	# (DW_AT_byte_size)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3e	# (DW_AT_encoding)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.byte	0
	.byte	0
	.uleb128 0x3	# (abbrev code)
	.uleb128 0x26	# (TAG: DW_TAG_const_type)
	.byte	0	# DW_children_no
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0x4	# (abbrev code)
	.uleb128 0x2e	# (TAG: DW_TAG_subprogram)
	.byte	0x1	# DW_children_yes
	.uleb128 0x3f	# (DW_AT_external)
	.uleb128 0x19	# (DW_FORM_flag_present)
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.uleb128 0x40	# (DW_AT_frame_base)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x2116	# (DW_AT_GNU_all_tail_call_sites)
	.uleb128 0x19	# (DW_FORM_flag_present)
	.uleb128 0x1	# (DW_AT_sibling)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0x5	# (abbrev code)
	.uleb128 0x5	# (TAG: DW_TAG_formal_parameter)
	.byte	0	# DW_children_no
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.uleb128 0x2	# (DW_AT_location)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.byte	0
	.byte	0
	.uleb128 0x6	# (abbrev code)
	.uleb128 0xf	# (TAG: DW_TAG_pointer_type)
	.byte	0	# DW_children_no
	.uleb128 0xb	# (DW_AT_byte_size)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0x7	# (abbrev code)
	.uleb128 0x2e	# (TAG: DW_TAG_subprogram)
	.byte	0x1	# DW_children_yes
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x6a	# (DW_AT_main_subprogram)
	.uleb128 0x19	# (DW_FORM_flag_present)
	.uleb128 0x36	# (DW_AT_calling_convention)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.uleb128 0x40	# (DW_AT_frame_base)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x2116	# (DW_AT_GNU_all_tail_call_sites)
	.uleb128 0x19	# (DW_FORM_flag_present)
	.uleb128 0x1	# (DW_AT_sibling)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0x8	# (abbrev code)
	.uleb128 0x34	# (TAG: DW_TAG_variable)
	.byte	0	# DW_children_no
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0x8	# (DW_FORM_string)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0x9	# (abbrev code)
	.uleb128 0x34	# (TAG: DW_TAG_variable)
	.byte	0	# DW_children_no
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0xe	# (DW_FORM_strp)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.uleb128 0x2	# (DW_AT_location)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.byte	0
	.byte	0
	.uleb128 0xa	# (abbrev code)
	.uleb128 0x34	# (TAG: DW_TAG_variable)
	.byte	0	# DW_children_no
	.uleb128 0x3	# (DW_AT_name)
	.uleb128 0x8	# (DW_FORM_string)
	.uleb128 0x3a	# (DW_AT_decl_file)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x3b	# (DW_AT_decl_line)
	.uleb128 0xb	# (DW_FORM_data1)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.uleb128 0x2	# (DW_AT_location)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.byte	0
	.byte	0
	.uleb128 0xb	# (abbrev code)
	.uleb128 0xb	# (TAG: DW_TAG_lexical_block)
	.byte	0x1	# DW_children_yes
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.byte	0
	.byte	0
	.uleb128 0xc	# (abbrev code)
	.uleb128 0xb	# (TAG: DW_TAG_lexical_block)
	.byte	0x1	# DW_children_yes
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.uleb128 0x1	# (DW_AT_sibling)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0xd	# (abbrev code)
	.uleb128 0xb	# (TAG: DW_TAG_lexical_block)
	.byte	0	# DW_children_no
	.uleb128 0x11	# (DW_AT_low_pc)
	.uleb128 0x1	# (DW_FORM_addr)
	.uleb128 0x12	# (DW_AT_high_pc)
	.uleb128 0x6	# (DW_FORM_data4)
	.byte	0
	.byte	0
	.uleb128 0xe	# (abbrev code)
	.uleb128 0x1	# (TAG: DW_TAG_array_type)
	.byte	0x1	# DW_children_yes
	.uleb128 0x50	# (DW_AT_data_location)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x4f	# (DW_AT_associated)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.uleb128 0x1	# (DW_AT_sibling)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.uleb128 0xf	# (abbrev code)
	.uleb128 0x21	# (TAG: DW_TAG_subrange_type)
	.byte	0	# DW_children_no
	.uleb128 0x22	# (DW_AT_lower_bound)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x2f	# (DW_AT_upper_bound)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x51	# (DW_AT_byte_stride)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.byte	0
	.byte	0
	.uleb128 0x10	# (abbrev code)
	.uleb128 0x1	# (TAG: DW_TAG_array_type)
	.byte	0x1	# DW_children_yes
	.uleb128 0x50	# (DW_AT_data_location)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x4e	# (DW_AT_allocated)
	.uleb128 0x18	# (DW_FORM_exprloc)
	.uleb128 0x49	# (DW_AT_type)
	.uleb128 0x13	# (DW_FORM_ref4)
	.byte	0
	.byte	0
	.byte	0
	.section	.debug_aranges,"",@progbits
	.long	0x1c	# Length of Address Ranges Info
	.value	0x2	# DWARF Version
	.long	.Ldebug_info0	# Offset of Compilation Unit Info
	.byte	0x4	# Size of Address
	.byte	0	# Size of Segment Descriptor
	.value	0	# Pad to 8 byte boundary
	.value	0
	.long	.Ltext0	# Address
	.long	.Letext0-.Ltext0	# Length
	.long	0
	.long	0
	.section	.debug_line,"",@progbits
.Ldebug_line0:
	.section	.debug_str,"MS",@progbits,1
.LASF7:
	.string	"/home/jkratoch/redhat/gdb-clean/gdb/testsuite"
.LASF3:
	.string	"character(kind=1)"
.LASF0:
	.string	"argc"
.LASF9:
	.string	"vla_stride"
.LASF2:
	.string	"integer(kind=4)"
.LASF5:
	.string	"GNU Fortran2008 6.1.1 20160621 (Red Hat 6.1.1-3) -m32 -mtune=generic -march=i686 -g -fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/finclude"
.LASF8:
	.string	"main"
.LASF4:
	.string	"pvla"
.LASF6:
	.string	"gdb.fortran/vla-stride.f90"
.LASF1:
	.string	"argv"
	.ident	"GCC: (GNU) 6.1.1 20160621 (Red Hat 6.1.1-3)"
	.section	.note.GNU-stack,"",@progbits

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-25 17:06                           ` Jan Kratochvil
@ 2016-08-25 17:22                             ` Jan Kratochvil
  2016-08-26  7:17                               ` Jan Kratochvil
  2016-09-02 13:44                             ` Bernhard Heckel
  1 sibling, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-08-25 17:22 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

On Thu, 25 Aug 2016 19:06:26 +0200, Jan Kratochvil wrote:
> I have attached a fix.

That fix has a regression for normal (64-bit) inferiors.

I see the source handles negative stide specially.  Particularly the comment
here does not explain the code it comments:

      /* Adjust the data location with the value of byte stride if set, which
         can describe the separation between successive elements along the
         dimension.  */
      if (TYPE_BYTE_STRIDE (range_type) < 0)
        value += (TYPE_HIGH_BOUND (range_type) - TYPE_LOW_BOUND (range_type))
                  * TYPE_BYTE_STRIDE (range_type);
  else if (elt_stride < 0)
    {
      int offs = (elt_offs + 1) * elt_stride;

      elt_offs = TYPE_LENGTH (array_type) + offs;
    }

But I do not negative stride values described in DWARF-4 anyhow.  When it is
used?  With this interpretation of stride the gfortran random(?) stride value
for arrays with single row would be really wrong.  But I do not see
a definition of negative stride in DWARF.


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-25 17:22                             ` Jan Kratochvil
@ 2016-08-26  7:17                               ` Jan Kratochvil
  2016-09-01 10:11                                 ` Bernhard Heckel
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-08-26  7:17 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Thu, 25 Aug 2016 19:22:17 +0200, Jan Kratochvil wrote:
> I see the source handles negative stide specially.  Particularly the comment
> here does not explain the code it comments:

With the attached patch disabling these cases still the supplied
gdb.fortran/static-arrays.exp and gdb.fortran/vla-stride.exp PASS (on Fedora 24
x86_64).


Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 1222 bytes --]

diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 88801ac..695825a 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -2197,12 +2197,14 @@ resolve_dynamic_type_internal (struct type *type,
     {
       struct type *range_type = TYPE_INDEX_TYPE (resolved_type);
 
+#if 0
       /* Adjust the data location with the value of byte stride if set, which
          can describe the separation between successive elements along the
          dimension.  */
       if (TYPE_BYTE_STRIDE (range_type) < 0)
         value += (TYPE_HIGH_BOUND (range_type) - TYPE_LOW_BOUND (range_type))
                   * TYPE_BYTE_STRIDE (range_type);
+#endif
 
       TYPE_DATA_LOCATION_ADDR (resolved_type) = value;
       TYPE_DATA_LOCATION_KIND (resolved_type) = PROP_CONST;
diff --git a/gdb/valarith.c b/gdb/valarith.c
index 9093969..eca7992 100644
--- a/gdb/valarith.c
+++ b/gdb/valarith.c
@@ -199,12 +199,14 @@ value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound)
 
   if (elt_stride > 0)
     elt_offs *= elt_stride;
+#if 0
   else if (elt_stride < 0)
     {
       int offs = (elt_offs + 1) * elt_stride;
 
       elt_offs = TYPE_LENGTH (array_type) + offs;
     }
+#endif
   else
     elt_offs *= elt_size;
 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-23 13:34                         ` Bernhard Heckel
  2016-08-25 17:06                           ` Jan Kratochvil
@ 2016-09-01  9:48                           ` Jan Kratochvil
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-01  9:48 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote:
> created a branch with all stride patches.

users/bheckel/fortran-strides
2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b


> I don't see regression on RH7.1, gcc 4.8.3-9

I see a regression in Fedora-specific testcase, attaching it also with a fix.

Although it does not work just on your branch, apparently it has some
dependency on other Fedora patches.
	http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/tree/
It can be resolved later for upstream GDB I guess.


Jan

[-- Attachment #2: gdb-vla-intel-stringbt-fix.patch --]
[-- Type: text/plain, Size: 6873 bytes --]

http://sourceware.org/ml/gdb-patches/2014-08/msg00025.html
Subject: [patch 1/2] Re: Crash regression(?) printing Fortran strings in bt  [Re: [V2 00/23] Fortran dynamic array support]


--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, 01 Aug 2014 09:20:19 +0200, Keven Boell wrote:
> I just tried it on Fedora 20 i686.  Applied the patch, you mentioned, on top of
> the Fortran VLA series and executed your dynamic-other-frame test.  Everything
> is working fine here, I cannot reproduce the crash.

I have it reproducible on Fedora 20 i686 with plain
CFLAGS=-g ./configure;make;cd gdb/testsuite;make site.exp;runtest gdb.fortran/dynamic-other-frame.exp

Besides that I have updated the testcase with
	gdb_test_no_output "set print frame-arguments all"
so that there is no longer needed the patch:
	[patch] Display Fortran strings in backtraces
	https://sourceware.org/ml/gdb-patches/2014-07/msg00709.html

The fix below has no regressions for me.  Unfortunately I do not see why you
cannot reproduce it.


Thanks,
Jan

--- ./gdb/dwarf2loc.c	2016-08-29 04:01:25.000000000 +0200
+++ ./gdb/dwarf2loc.c	2016-09-01 11:00:20.258909494 +0200
@@ -2289,6 +2289,15 @@ const struct dwarf_expr_context_funcs dw
   dwarf_expr_get_obj_addr
 };
 
+static void
+select_frame_cleanup (void *arg)
+{
+  struct frame_info *frame = (struct frame_info *) arg;
+
+  if (frame != NULL)
+    select_frame (frame);
+}
+
 /* Evaluate a location description, starting at DATA and with length
    SIZE, to find the current location of variable of TYPE in the
    context of FRAME.  BYTE_OFFSET is applied after the contents are
@@ -2318,6 +2327,11 @@ dwarf2_evaluate_loc_desc_full (struct ty
 
   ctx = new_dwarf_expr_context ();
   old_chain = make_cleanup_free_dwarf_expr_context (ctx);
+
+  make_cleanup (select_frame_cleanup, deprecated_safe_get_selected_frame ());
+  if (frame != NULL)
+    select_frame (frame);
+
   value_chain = make_cleanup_value_free_to_mark (value_mark ());
 
   ctx->gdbarch = get_objfile_arch (objfile);
Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90	2015-05-31 16:14:05.844545344 +0200
@@ -0,0 +1,24 @@
+! Copyright 2010 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 2 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program; if not, write to the Free Software
+! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+!
+! Ihis file is the Fortran source file for dynamic.exp.
+! Original file written by Jakub Jelinek <jakub@redhat.com>.
+! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+subroutine bar
+  real :: dummy
+  dummy = 1
+end subroutine bar
Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.exp
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.exp	2015-05-31 16:14:05.845545351 +0200
@@ -0,0 +1,39 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+set testfile "dynamic-other-frame"
+set srcfile1 ${testfile}.f90
+set srcfile2 ${testfile}-stub.f90
+set objfile2 [standard_output_file ${testfile}-stub.o]
+set executable ${testfile}
+set binfile [standard_output_file ${executable}]
+
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${objfile2}" object {f90}] != ""
+     || [gdb_compile "${srcdir}/${subdir}/${srcfile1} ${objfile2}" "${binfile}" executable {debug f90}] != "" } {
+    untested "Couldn't compile ${srcfile1} or ${srcfile2}"
+    return -1
+}
+
+clean_restart ${executable}
+
+gdb_test_no_output "set print frame-arguments all"
+
+if ![runto bar_] then {
+    perror "couldn't run to bar_"
+    continue
+}
+
+gdb_test "bt" {foo \(string='hello'.*}
Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.f90
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.f90	2015-05-31 16:14:05.845545351 +0200
@@ -0,0 +1,36 @@
+! Copyright 2010 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 2 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program; if not, write to the Free Software
+! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+!
+! Ihis file is the Fortran source file for dynamic.exp.
+! Original file written by Jakub Jelinek <jakub@redhat.com>.
+! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+subroutine foo (string)
+  interface
+    subroutine bar
+    end subroutine
+  end interface
+  character string*(*)
+  call bar                                ! stop-here
+end subroutine foo
+program test
+  interface
+    subroutine foo (string)
+    character string*(*)
+    end subroutine
+  end interface
+  call foo ('hello')
+end

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-26  7:17                               ` Jan Kratochvil
@ 2016-09-01 10:11                                 ` Bernhard Heckel
  0 siblings, 0 replies; 26+ messages in thread
From: Bernhard Heckel @ 2016-09-01 10:11 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 26/08/2016 09:17, Jan Kratochvil wrote:
> On Thu, 25 Aug 2016 19:22:17 +0200, Jan Kratochvil wrote:
>> I see the source handles negative stide specially.  Particularly the comment
>> here does not explain the code it comments:
> With the attached patch disabling these cases still the supplied
> gdb.fortran/static-arrays.exp and gdb.fortran/vla-stride.exp PASS (on Fedora 24
> x86_64).
>
>
> Jan
Hi Jan,

I am just setting up a Fedora24 environment. I will look into this 
stride issue and update the branch
with your current findings.


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-08-25 17:06                           ` Jan Kratochvil
  2016-08-25 17:22                             ` Jan Kratochvil
@ 2016-09-02 13:44                             ` Bernhard Heckel
  2016-09-04 17:15                               ` Jan Kratochvil
  1 sibling, 1 reply; 26+ messages in thread
From: Bernhard Heckel @ 2016-09-02 13:44 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 25/08/2016 19:06, Jan Kratochvil wrote:
> On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote:
>> created a branch with all stride patches.
> users/bheckel/fortran-strides
> 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b
>
>> I don't see regression on RH7.1, gcc 4.8.3-9
> I see a regression for 32-bit targets (x86_64-m32 or native i686)
> on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64).  I do not see the regression
> on CentOS-7.2 (x86_64-m32).
>
> print pvla^M
> value requires 4294967288 bytes, which is more than max-value-size^M
> (gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element
>
> I have attached a fix.
>
> It is because:
>      <115>   DW_AT_lower_bound : 4 byte block: 97 23 10 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 16; DW_OP_deref)
>      <11a>   DW_AT_upper_bound : 4 byte block: 97 23 14 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 20; DW_OP_deref)
>      <11f>   DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e   (DW_OP_push_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
> 	DW_AT_lower_bound == 1
> 	DW_AT_upper_bound == 1
> 	DW_AT_byte_stride == (-2) * 4 == -8
>
> I am not sure if gfortran is really wrong or not but a stride does not make
> sense for me for a single row array.
>
> Attaching also gdb.fortran/vla-stride.f90 from your branch built with
> gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode.
>
> Besides that I see on all archs
> 	-FAIL: gdb.pascal/arrays.exp: Print dynamic array of string
> 	+FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB internal error)
> but that testcase is only in Fedora and the Pascal (fpc) support has been not
> well maintained so far so I am OK with that.
>
>
> Thanks,
> Jan
Hi Jan,

found the root cause of the issue on 32bit inferior.
According to DWARF4 (Page 100) strides can be negative but evaluation of 
dynamic properties in GDB is done via CORE_ADDR which is unsigned.
This causes the issue that the type length seems to be way to big.

The following code is not claimed to be a fix, just want to point you to 
the right direction.
In gdbtypes.c:
   prop = &TYPE_RANGE_DATA (dyn_range_type)->stride;
   if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
     {
       /* if target is 32bit, execute next if clause  */
       if (value > (2^31))
     value += 2^32;

       stride.kind = PROP_CONST;
       stride.data.const_val = value;
     }
Also, in dwarf2read.c all DW_AT_...STRIDE 's are handles as unsigned. 
This has to be fixed as well.

I will investigate more on the stride topic next week.


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-02 13:44                             ` Bernhard Heckel
@ 2016-09-04 17:15                               ` Jan Kratochvil
  2016-09-07 10:29                                 ` Bernhard Heckel
  2016-09-07 20:24                                 ` Jan Kratochvil
  0 siblings, 2 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-04 17:15 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote:
> dynamic properties in GDB is done via CORE_ADDR which is unsigned.
> This causes the issue that the type length seems to be way to big.

Maybe that explains also a regression visible only on i686 (32-bit host).
It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior
(-m32):

The length is bogus (it is %rax or %eax) but it should be some number.

i686:
ptype reg_string^M
type = char [variable length]^M
             ^^^^^^^^^^^^^^^
(gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string
p reg_string^M
Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M

x86_64 or x86_64 -m32:
ptype reg_string^M
type = char [4160048541]^M
(gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string

Attaching the Fedora testcase.


Thanks,
Jan

[-- Attachment #2: dw2-bound-loclist.patch --]
[-- Type: text/plain, Size: 10906 bytes --]

--- /dev/null	2016-08-23 22:46:08.455975850 +0200
+++ gdb-7.11.90.20160904/gdb/testsuite/gdb.dwarf2/dw2-bound-loclist.exp	2016-09-04 19:09:23.719880045 +0200
@@ -0,0 +1,66 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test printing variable with dynamic bounds which reference a different
+# (artificial in the GCC case) variable containing loclist as its location.
+# This testcase uses value (not address) of the referenced variable:
+# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762
+
+# This test can only be run on targets which support DWARF-2 and use gas.
+# For now pick a sampling of likely targets.
+if {![istarget *-*-linux*]
+    && ![istarget *-*-gnu*]
+    && ![istarget *-*-elf*]
+    && ![istarget *-*-openbsd*]
+    && ![istarget arm-*-eabi*]
+    && ![istarget powerpc-*-eabi*]} {
+    return 0
+}
+
+set testfile dw2-bound-loclist
+if { [prepare_for_testing ${testfile}.exp ${testfile} [list ${testfile}.S main.c] {}] } {
+    return -1
+}
+
+# Verify it behaves at least as an unbound array without inferior.
+
+# FIXME: FSF GDB crashes due to !has_stack_frames ().
+# But in practice that should not happen.
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762
+#set test "p a_string"
+#gdb_test_multiple $test $test {
+#    -re " = 0x\[0-9a-f\]+ \"seennotseen\"\r\n$gdb_prompt $" {
+#	pass $test
+#    }
+#    -re "No registers\\.\r\n$gdb_prompt $" {
+#	kfail "vlaregression" $test
+#    }
+#}
+#
+#gdb_test "ptype a_string" {type = char \[variable length\]}
+
+# Not runto_main as dw2-bound-loclist.S handles only the first byte of main.
+if ![runto "*main"] {
+    return -1
+}
+
+gdb_test "p a_string" { = "seen"}
+gdb_test "ptype a_string" {type = char \[4\]}
+
+gdb_test "p b_string" { = (0x[0-9a-f]+ )?"seennotseen"}
+gdb_test "ptype b_string" {type = char \[\]}
+
+# The register contains unpredictable value - the array size.
+gdb_test "ptype reg_string" {type = char \[-?[0-9]+\]}
--- /dev/null	2016-08-23 22:46:08.455975850 +0200
+++ gdb-7.11.90.20160904/gdb/testsuite/gdb.dwarf2/dw2-bound-loclist.S	2016-09-04 19:09:23.719880045 +0200
@@ -0,0 +1,246 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2010 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* Debug information */
+
+/* We will `break *main' at the very first instruction.  */
+#define main_length 1
+
+	.section	.data
+vardata:
+	/* See DW_OP_lit3 + 1 (0-based).  */
+	.string		"seennotseen"
+
+	.section	.debug_info
+.Lcu1_begin:
+	.4byte		.Lcu1_end - .Lcu1_start	/* Length of Compilation Unit */
+.Lcu1_start:
+	.2byte		2			/* DWARF version number */
+	.4byte		.Ldebug_abbrev0		/* Offset Into Abbrev. Section */
+	.byte		4			/* Pointer Size (in bytes) */
+
+	/* CU die */
+	.uleb128	1			/* Abbrev: DW_TAG_compile_unit */
+	.4byte		.Lproducer		/* DW_AT_producer */
+	/* Use C++ to exploit a bug in parsing DW_AT_name "".  */
+	.byte		4			/* DW_AT_language (C++) -  */
+	.4byte		main			/* DW_AT_low_pc */
+	.byte		main_length		/* DW_AT_high_pc */
+
+.Larray_type:
+	.uleb128	2			/* Abbrev: DW_TAG_array_type */
+	.4byte		.Lchar_type-.Lcu1_begin	/* DW_AT_type */
+
+	.uleb128	3			/* Abbrev: DW_TAG_subrange_type */
+	.4byte		.Luint_type-.Lcu1_begin	/* DW_AT_type */
+	.byte		0			/* DW_AT_lower_bound */
+	.4byte		.Llen_var-.Lcu1_begin	/* DW_AT_upper_bound */
+	.byte		0			/* End of children of die */
+
+	/* DW_AT_upper_bound is referencing an optimized-out variable.  */
+.Larrayb_type:
+	.uleb128	2			/* Abbrev: DW_TAG_array_type */
+	.4byte		.Lchar_type-.Lcu1_begin	/* DW_AT_type */
+
+	.uleb128	3			/* Abbrev: DW_TAG_subrange_type */
+	.4byte		.Luint_type-.Lcu1_begin	/* DW_AT_type */
+	.byte		0			/* DW_AT_lower_bound */
+	.4byte		.Llenb_var-.Lcu1_begin	/* DW_AT_upper_bound */
+	.byte		0			/* End of children of die */
+
+	/* DW_AT_upper_bound is referencing register.  */
+.Larrayreg_type:
+	.uleb128	2			/* Abbrev: DW_TAG_array_type */
+	.4byte		.Lchar_type-.Lcu1_begin	/* DW_AT_type */
+
+	.uleb128	8			/* Abbrev: DW_TAG_subrange_type with block */
+	.4byte		.Luint_type-.Lcu1_begin	/* DW_AT_type */
+	.byte		0			/* DW_AT_lower_bound */
+	.byte		2f - 1f			/* DW_AT_upper_bound */
+1:	.byte		0x50			/* DW_OP_reg0 */
+2:
+	.byte		0			/* End of children of die */
+
+.Luint_type:
+	.uleb128	4			/* Abbrev: DW_TAG_base_type */
+	.4byte		.Luint_str		/* DW_AT_name */
+	.byte		4			/* DW_AT_byte_size */
+	.byte		7			/* DW_AT_encoding */
+
+.Lchar_type:
+	.uleb128	4			/* Abbrev: DW_TAG_base_type */
+	.4byte		.Lchar_str		/* DW_AT_name */
+	.byte		1			/* DW_AT_byte_size */
+	.byte		6			/* DW_AT_encoding */
+
+.Llen_var:
+	.uleb128	5			/* Abbrev: DW_TAG_variable artificial */
+	.byte		1			/* DW_AT_artificial */
+	.4byte		.Luint_type-.Lcu1_begin	/* DW_AT_type */
+	.4byte		.Llen_loclist-.Lloclist	/* DW_AT_location */
+
+	/* optimized-out variable for b_string.  */
+.Llenb_var:
+	.uleb128	7			/* Abbrev: DW_TAG_variable artificial no DW_AT_location */
+	.byte		1			/* DW_AT_artificial */
+	.4byte		.Luint_type-.Lcu1_begin	/* DW_AT_type */
+
+	.uleb128	6			/* Abbrev: DW_TAG_variable DW_FORM_string */
+	.string		"a_string"		/* DW_AT_name */
+	.4byte		.Larray_type-.Lcu1_begin /* DW_AT_type */
+	.byte		2f - 1f			/* DW_AT_location */
+1:	.byte		3			/*   DW_OP_addr */
+	.4byte		vardata			/*   <addr> */
+2:
+
+	/* DW_AT_upper_bound is referencing an optimized-out variable.  */
+	.uleb128	6			/* Abbrev: DW_TAG_variable DW_FORM_string */
+	.string		"b_string"		/* DW_AT_name */
+	.4byte		.Larrayb_type-.Lcu1_begin /* DW_AT_type */
+	.byte		2f - 1f			/* DW_AT_location */
+1:	.byte		3			/*   DW_OP_addr */
+	.4byte		vardata			/*   <addr> */
+2:
+
+	/* DW_AT_upper_bound is referencing register.  */
+	.uleb128	6			/* Abbrev: DW_TAG_variable DW_FORM_string */
+	.string		"reg_string"		/* DW_AT_name */
+	.4byte		.Larrayreg_type-.Lcu1_begin /* DW_AT_type */
+	.byte		2f - 1f			/* DW_AT_location */
+1:	.byte		3			/*   DW_OP_addr */
+	.4byte		vardata			/*   <addr> */
+2:
+
+	.byte		0			/* End of children of CU */
+.Lcu1_end:
+
+	.section	.debug_loc
+.Lloclist:
+.Llen_loclist:
+	.4byte	0			# Location list begin address
+	.4byte	main_length		# Location list end address
+	.value	2f-1f	# Location expression size
+1:	.byte	0x33	# DW_OP_lit3
+	.byte	0x9f	# DW_OP_stack_value
+2:
+	.quad	0x0	# Location list terminator begin (*.LLST2)
+	.quad	0x0	# Location list terminator end (*.LLST2)
+
+	.section .debug_abbrev
+.Ldebug_abbrev0:
+	.uleb128	1			/* Abbrev code */
+	.uleb128	0x11			/* DW_TAG_compile_unit */
+	.byte		0x1			/* has_children */
+	.uleb128	0x25			/* DW_AT_producer */
+	.uleb128	0xe			/* DW_FORM_strp */
+	.uleb128	0x13			/* DW_AT_language */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.uleb128	0x11			/* DW_AT_low_pc */
+	.uleb128	0x1			/* DW_FORM_addr */
+	.uleb128	0x12			/* DW_AT_high_pc */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	2			/* Abbrev code */
+	.uleb128	0x1			/* TAG: DW_TAG_array_type */
+	.byte		0x1			/* DW_children_yes */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	3			/* Abbrev code */
+	.uleb128	0x21			/* DW_TAG_subrange_type */
+	.byte		0x0			/* no children */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.uleb128	0x22			/* DW_AT_lower_bound */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.uleb128	0x2f			/* DW_AT_upper_bound */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	4			/* Abbrev code */
+	.uleb128	0x24			/* DW_TAG_base_type */
+	.byte		0x0			/* no_children */
+	.uleb128	0x3			/* DW_AT_name */
+	.uleb128	0xe			/* DW_FORM_strp */
+	.uleb128	0xb			/* DW_AT_byte_size */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.uleb128	0x3e			/* DW_AT_encoding */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	5			/* Abbrev code */
+	.uleb128	0x34			/* DW_TAG_variable */
+	.byte		0x0			/* no_children */
+	.uleb128	0x34			/* DW_AT_artificial */
+	.uleb128	0x0c			/* DW_FORM_flag */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.uleb128	0x02			/* DW_AT_location */
+	.uleb128	0x06			/* DW_FORM_data4 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	6			/* Abbrev code */
+	.uleb128	0x34			/* DW_TAG_variable */
+	.byte		0x0			/* no_children */
+	.uleb128	0x3			/* DW_AT_name */
+	.uleb128	0x8			/* DW_FORM_string */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.uleb128	0x2			/* DW_AT_location */
+	.uleb128	0xa			/* DW_FORM_block1 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	7			/* Abbrev code */
+	.uleb128	0x34			/* DW_TAG_variable */
+	.byte		0x0			/* no_children */
+	.uleb128	0x34			/* DW_AT_artificial */
+	.uleb128	0x0c			/* DW_FORM_flag */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.uleb128	8			/* Abbrev code */
+	.uleb128	0x21			/* DW_TAG_subrange_type with block */
+	.byte		0x0			/* no children */
+	.uleb128	0x49			/* DW_AT_type */
+	.uleb128	0x13			/* DW_FORM_ref4 */
+	.uleb128	0x22			/* DW_AT_lower_bound */
+	.uleb128	0xb			/* DW_FORM_data1 */
+	.uleb128	0x2f			/* DW_AT_upper_bound */
+	.uleb128	0xa			/* DW_FORM_block1 */
+	.byte		0x0			/* Terminator */
+	.byte		0x0			/* Terminator */
+
+	.byte		0x0			/* Terminator */
+
+/* String table */
+	.section .debug_str
+.Lproducer:
+	.string		"GNU C 3.3.3"
+.Lchar_str:
+	.string		"char"
+.Luint_str:
+	.string		"unsigned int"

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-04 17:15                               ` Jan Kratochvil
@ 2016-09-07 10:29                                 ` Bernhard Heckel
  2016-09-07 20:05                                   ` Jan Kratochvil
  2016-09-12 21:05                                   ` Jan Kratochvil
  2016-09-07 20:24                                 ` Jan Kratochvil
  1 sibling, 2 replies; 26+ messages in thread
From: Bernhard Heckel @ 2016-09-07 10:29 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 04/09/2016 19:14, Jan Kratochvil wrote:
> On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote:
>> dynamic properties in GDB is done via CORE_ADDR which is unsigned.
>> This causes the issue that the type length seems to be way to big.
> Maybe that explains also a regression visible only on i686 (32-bit host).
> It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior
> (-m32):
>
> The length is bogus (it is %rax or %eax) but it should be some number.
>
> i686:
> ptype reg_string^M
> type = char [variable length]^M
>               ^^^^^^^^^^^^^^^
> (gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string
> p reg_string^M
> Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M
>
> x86_64 or x86_64 -m32:
> ptype reg_string^M
> type = char [4160048541]^M
> (gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string
>
> Attaching the Fedora testcase.
>
>
> Thanks,
> Jan
Hi Jan,

I just recreated my two user branches.
- Fixed should be "Werror indentation" on the vla-string branch
- Stride issues you reported in general (stride branch)
- Stride issues on 32bit appl. running on 64bit system (gdb) (stride branch)
- Fixed also neg. bounds on 32bit appl. running on 64bit system (stride 
branch)

Let me know your results for the two branches.


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-07 10:29                                 ` Bernhard Heckel
@ 2016-09-07 20:05                                   ` Jan Kratochvil
  2016-09-12 21:05                                   ` Jan Kratochvil
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-07 20:05 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote:
> I just recreated my two user branches.

users/bheckel/fortran-strides
users/bheckel/fortran-vla-strings


> - Fixed should be "Werror indentation" on the vla-string branch
> - Stride issues you reported in general (stride branch)
> - Stride issues on 32bit appl. running on 64bit system (gdb) (stride branch)
> - Fixed also neg. bounds on 32bit appl. running on 64bit system (stride
> branch)

Yes, confirming the 32-bit strides issues seem to be fixed, thank you very
much.

FYI I still need to carry this "selected_frame" patch for Fortran backtraces:
	https://sourceware.org/ml/gdb-patches/2016-09/msg00011.html
But I will need to reproduce it with FSF GDB sources first.


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-04 17:15                               ` Jan Kratochvil
  2016-09-07 10:29                                 ` Bernhard Heckel
@ 2016-09-07 20:24                                 ` Jan Kratochvil
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-07 20:24 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

On Sun, 04 Sep 2016 19:14:53 +0200, Jan Kratochvil wrote:
> On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote:
> > dynamic properties in GDB is done via CORE_ADDR which is unsigned.
> > This causes the issue that the type length seems to be way to big.
> 
> Maybe that explains also a regression visible only on i686 (32-bit host).
> It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior
> (-m32):
> 
> The length is bogus (it is %rax or %eax) but it should be some number.
> 
> i686:
> ptype reg_string^M
> type = char [variable length]^M
>              ^^^^^^^^^^^^^^^
> (gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string
> p reg_string^M
> Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M
> 
> x86_64 or x86_64 -m32:
> ptype reg_string^M
> type = char [4160048541]^M
> (gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string

Confirming also this specific issue got fixed today, great!


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-07 10:29                                 ` Bernhard Heckel
  2016-09-07 20:05                                   ` Jan Kratochvil
@ 2016-09-12 21:05                                   ` Jan Kratochvil
  2016-09-14  7:24                                     ` Bernhard Heckel
  1 sibling, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-12 21:05 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote:
> I just recreated my two user branches.

I see a regression against former Intel VLA patchset for the attached testcase.

gdb_test "p c40pt(2)" " = '1-hello.*"
p c40pt(2)^M
$2 = '\001\000\000\000\061-hello', ' ' <repeats 29 times>^M
(gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2)


Thanks,
Jan

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 3338 bytes --]

diff --git a/gdb/testsuite/gdb.fortran/dwarf-stride.exp b/gdb/testsuite/gdb.fortran/dwarf-stride.exp
new file mode 100644
index 0000000..d7b8bea
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/dwarf-stride.exp
@@ -0,0 +1,42 @@
+# Copyright 2009 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# This file was written by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+# This file is part of the gdb testsuite.  Array element stride must not be
+# specified in the number of elements but in a number of bytes instead.
+# Original problem:
+# (gdb) p c40pt(1)
+# $1 = '0-hello', ' ' <repeats 33 times>
+# (gdb) p c40pt(2)
+# warning: Fortran array stride not divisible by the element size
+
+set testfile dwarf-stride
+set srcfile ${testfile}.f90
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} {debug f90}] } {
+    return -1
+}
+
+if ![runto MAIN__] then {
+    perror "couldn't run to breakpoint MAIN__"
+    continue
+}
+
+gdb_breakpoint [gdb_get_line_number "break-here"]
+gdb_continue_to_breakpoint "break-here" ".*break-here.*"
+gdb_test "p c40pt(1)" " = '0-hello.*"
+gdb_test "p c40pt(2)" " = '1-hello.*"
diff --git a/gdb/testsuite/gdb.fortran/dwarf-stride.f90 b/gdb/testsuite/gdb.fortran/dwarf-stride.f90
new file mode 100644
index 0000000..e492b3a
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/dwarf-stride.f90
@@ -0,0 +1,40 @@
+! Copyright 2009 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 2 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program; if not, write to the Free Software
+! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+!
+! File written by Alan Matsuoka.
+
+program repro
+
+  type small_stride
+     character*40 long_string
+     integer      small_pad
+  end type small_stride
+
+  type(small_stride), dimension (20), target :: unpleasant
+  character*40, pointer, dimension(:):: c40pt
+
+  integer i
+
+  do i = 0,19
+     unpleasant(i+1)%small_pad = i+1
+     unpleasant(i+1)%long_string = char (ichar('0') + i) // '-hello'
+  end do
+
+  c40pt => unpleasant%long_string
+
+  print *, c40pt  ! break-here
+
+end program repro

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-12 21:05                                   ` Jan Kratochvil
@ 2016-09-14  7:24                                     ` Bernhard Heckel
  2016-09-14 12:53                                       ` Jan Kratochvil
  0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Heckel @ 2016-09-14  7:24 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches

On 12/09/2016 23:04, Jan Kratochvil wrote:
> On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote:
>> I just recreated my two user branches.
> I see a regression against former Intel VLA patchset for the attached testcase.
>
> gdb_test "p c40pt(2)" " = '1-hello.*"
> p c40pt(2)^M
> $2 = '\001\000\000\000\061-hello', ' ' <repeats 29 times>^M
> (gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2)
>
>
> Thanks,
> Jan
Hi Jan,

I tested with GCC 4.8.3 and IFORT 17.0.0. Both passes.

With Fedora24, GCC 6.1.1 I see the same results as you. Investigation is 
showing that
GCC 6.1.1 doesn't provide the stride information (DWARF) which results 
in incorrect offsets.

Are you going to file a bug for GCC?


BTW: Nice testcase
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-09-14  7:24                                     ` Bernhard Heckel
@ 2016-09-14 12:53                                       ` Jan Kratochvil
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-09-14 12:53 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches

On Wed, 14 Sep 2016 09:24:15 +0200, Bernhard Heckel wrote:
> With Fedora24, GCC 6.1.1 I see the same results as you. Investigation is
> showing that
> GCC 6.1.1 doesn't provide the stride information (DWARF) which results in
> incorrect offsets.
> 
> Are you going to file a bug for GCC?

Thanks for the investigation, sorry I did not verify that myself.

I have filed it as:
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-07-07  9:16   ` Bernhard Heckel
@ 2016-07-07  9:23     ` Jan Kratochvil
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Kratochvil @ 2016-07-07  9:23 UTC (permalink / raw)
  To: Bernhard Heckel; +Cc: Keven Boell, gdb-patches

Hello Bernhard,

On Thu, 07 Jul 2016 11:16:05 +0200, Bernhard Heckel wrote:
> I propose to create a branch on the GDB repo, containing all the bugfixes
> and features I have.
> => users/bheckel/fortran

that is a great idea,

> List of features, working on current mainline code:
> - Pointers, under review at the moment
> - Variable Length Strings

just I would prefer a separate branch for each of these features.

Besides more flexible upstreaming personally I am interested now in off-trunk
VLA branch but probably not in the other off-trunk branches (as that
functionality was not present in current/former Fedora GDB versions so missing
those features is not a regression).


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2016-07-07  8:30 ` Jan Kratochvil
@ 2016-07-07  9:16   ` Bernhard Heckel
  2016-07-07  9:23     ` Jan Kratochvil
  0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Heckel @ 2016-07-07  9:16 UTC (permalink / raw)
  To: Jan Kratochvil, Keven Boell; +Cc: gdb-patches

On 07/07/2016 10:30, Jan Kratochvil wrote:
> Hello Keven,
>
> On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
>> This patch series add Fortran dynamic array support to gdb.
> this series is 1.5 years old and some partial upstreaming is also 1 year old,
> do you have some up-to-date remaining parts against FSF GDB trunk?
>
> I am trying to rebase it myself but just if you do not have it prepared
> already.
>
>
> Thanks,
> Jan
Hi Jan,

I took over the Fortran patches from Keven and drive implementation of 
new features and bugfixes.

I propose to create a branch on the GDB repo, containing all the 
bugfixes and features I have.
=> users/bheckel/fortran

List of features, working on current mainline code:
- Pointers, under review at the moment
- Variable Length Strings
- Alternative Entry Points
- Extended types, Access members via fully qualified name
- Setting breakpoints on internal subroutines
- OOP, print access label of types (private, public)

Bugfix:
- Handle nameless block-data, GDB will crash during read of DWARF content.

TBD:
- Intrinsic's are in the series from Keven, but I haven't took a look on 
those.


Regards,
Bernhard
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2015-01-14 13:49 Keven Boell
  2015-05-28 20:36 ` Jan Kratochvil
  2015-06-14  8:15 ` Jan Kratochvil
@ 2016-07-07  8:30 ` Jan Kratochvil
  2016-07-07  9:16   ` Bernhard Heckel
  2 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2016-07-07  8:30 UTC (permalink / raw)
  To: Keven Boell; +Cc: gdb-patches

Hello Keven,

On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
> This patch series add Fortran dynamic array support to gdb.

this series is 1.5 years old and some partial upstreaming is also 1 year old,
do you have some up-to-date remaining parts against FSF GDB trunk?

I am trying to rebase it myself but just if you do not have it prepared
already.


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2015-06-17 11:42   ` Boell, Keven
@ 2015-07-01 12:43     ` Keven Boell
  0 siblings, 0 replies; 26+ messages in thread
From: Keven Boell @ 2015-07-01 12:43 UTC (permalink / raw)
  To: Boell, Keven, Jan Kratochvil; +Cc: gdb-patches

https://sourceware.org/ml/gdb-patches/2015-07/msg00019.html

Keven

On 17.06.2015 13:41, Boell, Keven wrote:
> Hi Jan,
> 
> I didn't have much time to work on an updated VLA series. However, as there
> seems to be demand, I'll try to get an update to the mailing list by next
> week.
> 
> Keven
> 
> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] 
> Sent: Sunday, June 14, 2015 10:15 AM
> To: Boell, Keven
> Cc: gdb-patches@sourceware.org
> Subject: Re: [V4 00/21] Fortran dynamic array support
> 
> Hello,
> 
> On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
>> This patch series add Fortran dynamic array support to gdb.
> 
> does Intel some work in progress or plans for slices/subsets?  It is a
> working
> feature in gfortran but currently not in GDB:
> 	
> http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n
> 2295
> 	p var(1, 2:) = (21, 31)
> 	p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34))
> 	p var(:) = Wrong number of subscripts
> 	p var(:, :, :) = Wrong number of subscripts
> 
> 
> Jan
> 
> 
> 
> 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
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [V4 00/21] Fortran dynamic array support
  2015-06-14  8:15 ` Jan Kratochvil
@ 2015-06-17 11:42   ` Boell, Keven
  2015-07-01 12:43     ` Keven Boell
  0 siblings, 1 reply; 26+ messages in thread
From: Boell, Keven @ 2015-06-17 11:42 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: gdb-patches


[-- Attachment #1.1: Type: text/plain, Size: 915 bytes --]

Hi Jan,

I didn't have much time to work on an updated VLA series. However, as there
seems to be demand, I'll try to get an update to the mailing list by next
week.

Keven

-----Original Message-----
From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] 
Sent: Sunday, June 14, 2015 10:15 AM
To: Boell, Keven
Cc: gdb-patches@sourceware.org
Subject: Re: [V4 00/21] Fortran dynamic array support

Hello,

On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
> This patch series add Fortran dynamic array support to gdb.

does Intel some work in progress or plans for slices/subsets?  It is a
working
feature in gfortran but currently not in GDB:
	
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n
2295
	p var(1, 2:) = (21, 31)
	p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34))
	p var(:) = Wrong number of subscripts
	p var(:, :, :) = Wrong number of subscripts


Jan

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6608 bytes --]

[-- Attachment #2: Type: text/plain, Size: 331 bytes --]

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2015-01-14 13:49 Keven Boell
  2015-05-28 20:36 ` Jan Kratochvil
@ 2015-06-14  8:15 ` Jan Kratochvil
  2015-06-17 11:42   ` Boell, Keven
  2016-07-07  8:30 ` Jan Kratochvil
  2 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2015-06-14  8:15 UTC (permalink / raw)
  To: Keven Boell; +Cc: gdb-patches

Hello,

On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
> This patch series add Fortran dynamic array support to gdb.

does Intel some work in progress or plans for slices/subsets?  It is a working
feature in gfortran but currently not in GDB:
	http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n2295
	p var(1, 2:) = (21, 31)
	p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34))
	p var(:) = Wrong number of subscripts
	p var(:, :, :) = Wrong number of subscripts


Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2015-05-28 20:36 ` Jan Kratochvil
@ 2015-05-28 20:52   ` Joel Brobecker
  0 siblings, 0 replies; 26+ messages in thread
From: Joel Brobecker @ 2015-05-28 20:52 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Keven Boell, gdb-patches, Pedro Alves

> > This patch series add Fortran dynamic array support to gdb.
> I think this patch series is still not checked in, is it right?

The latest update on the patch series is that we worked towards
having a way to add dynamic attributes without always adding
an extra field in (space-critical) struct type. The next step
was to create a minimalistic patch that adds support for one
of the array properties, and then work our way up. This is to
allow both of us to understand the circumstances that explained
the need for each hunk, because I couldn't figure it out myself.

-- 
Joel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [V4 00/21] Fortran dynamic array support
  2015-01-14 13:49 Keven Boell
@ 2015-05-28 20:36 ` Jan Kratochvil
  2015-05-28 20:52   ` Joel Brobecker
  2015-06-14  8:15 ` Jan Kratochvil
  2016-07-07  8:30 ` Jan Kratochvil
  2 siblings, 1 reply; 26+ messages in thread
From: Jan Kratochvil @ 2015-05-28 20:36 UTC (permalink / raw)
  To: Keven Boell; +Cc: gdb-patches, Pedro Alves

Hello,

On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote:
> This patch series add Fortran dynamic array support to gdb.

I think this patch series is still not checked in, is it right?

Do you have its more recent / rebased variant?


Thanks,
Jan

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [V4 00/21] Fortran dynamic array support
@ 2015-01-14 13:49 Keven Boell
  2015-05-28 20:36 ` Jan Kratochvil
                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Keven Boell @ 2015-01-14 13:49 UTC (permalink / raw)
  To: gdb-patches; +Cc: Keven Boell

This patch series add Fortran dynamic array support to gdb.

It allows the user to evaluate a dynamic array like an ordinary static array
e.g. print its elements instead of printing the pointer to the array.
In addition the size of a dynamic array can be retrieved with gdbs builtin
sizeof operator. Furthermore this series add support for Fortran stride support.

	1| integer, allocatable :: ary(:)
	2| allocate(ary(5))
	3| ary(:) = 42

	(gdb) print ary
	$1 = (42, 42, 42, 42, 42)

	(gdb) print sizeof (ary)
	$2 = 20

	(gdb) ptype ary
	type = integer(kind=4) (5)

This series is a follow up for the following C99 variable length array
support series:
	https://sourceware.org/ml/gdb-patches/2013-12/msg00625.html

Patch series V4 restructures the patches into more logical parts. Tests
were added directly to the functional changes, instead of the main dynamic
array tests to avoid one huge patch.

Keven Boell (18):
  vla: introduce allocated/associated flags
  vla: make dynamic fortran arrays functional.
  test: basic tests for dynamic array evaluations in Fortran.
  test: evaluate dynamic arrays using Fortran primitives.
  test: dynamic arrays passed to subroutines.
  test: correct ptype of dynamic arrays in Fortran.
  test: evaluating allocation/association status
  test: dynamic arrays passed to functions.
  test: accessing dynamic array history values.
  test: basic MI test for the dynamic array support.
  test: test sizeof for dynamic fortran arrays.
  test: add archer dynamic other frame test
  vla: reconstruct value to compute bounds of target type
  vla: use value constructor instead of raw-buffer manipulation
  vla: get dynamic array corner cases to work
  vla: Fortran dynamic string support
  vla: add stride support to fortran arrays.
  vla: add NEWS entry for dynamic array support

 gdb/NEWS                                           |    3 +
 gdb/c-valprint.c                                   |   11 +-
 gdb/dwarf2loc.c                                    |   16 ++
 gdb/dwarf2loc.h                                    |    6 +
 gdb/dwarf2read.c                                   |  181 +++++++++++++++++--
 gdb/f-typeprint.c                                  |   68 +++++---
 gdb/f-valprint.c                                   |  124 +++++--------
 gdb/gdbtypes.c                                     |  167 ++++++++++++++++--
 gdb/gdbtypes.h                                     |   43 +++++
 .../gdb.fortran/dynamic-other-frame-stub.f90       |   24 +++
 gdb/testsuite/gdb.fortran/dynamic-other-frame.exp  |   39 +++++
 gdb/testsuite/gdb.fortran/dynamic-other-frame.f90  |   36 ++++
 gdb/testsuite/gdb.fortran/vla-alloc-assoc.exp      |   65 +++++++
 gdb/testsuite/gdb.fortran/vla-datatypes.exp        |   82 +++++++++
 gdb/testsuite/gdb.fortran/vla-datatypes.f90        |   51 ++++++
 gdb/testsuite/gdb.fortran/vla-func.exp             |   61 +++++++
 gdb/testsuite/gdb.fortran/vla-func.f90             |   71 ++++++++
 gdb/testsuite/gdb.fortran/vla-history.exp          |   62 +++++++
 gdb/testsuite/gdb.fortran/vla-ptr-info.exp         |   32 ++++
 gdb/testsuite/gdb.fortran/vla-ptype-sub.exp        |   87 ++++++++++
 gdb/testsuite/gdb.fortran/vla-ptype.exp            |   96 +++++++++++
 gdb/testsuite/gdb.fortran/vla-sizeof.exp           |   46 +++++
 gdb/testsuite/gdb.fortran/vla-stride.exp           |   44 +++++
 gdb/testsuite/gdb.fortran/vla-stride.f90           |   30 ++++
 gdb/testsuite/gdb.fortran/vla-strings.exp          |  104 +++++++++++
 gdb/testsuite/gdb.fortran/vla-strings.f90          |   40 +++++
 gdb/testsuite/gdb.fortran/vla-sub.f90              |   82 +++++++++
 .../gdb.fortran/vla-value-sub-arbitrary.exp        |   35 ++++
 gdb/testsuite/gdb.fortran/vla-value-sub-finish.exp |   49 ++++++
 gdb/testsuite/gdb.fortran/vla-value-sub.exp        |   90 ++++++++++
 gdb/testsuite/gdb.fortran/vla-value.exp            |  148 ++++++++++++++++
 gdb/testsuite/gdb.fortran/vla.f90                  |   56 ++++++
 gdb/testsuite/gdb.mi/mi-vla-fortran.exp            |  182 ++++++++++++++++++++
 gdb/testsuite/gdb.mi/vla.f90                       |   42 +++++
 gdb/typeprint.c                                    |    7 +
 gdb/valarith.c                                     |   23 ++-
 gdb/valprint.c                                     |   40 +++++
 gdb/valprint.h                                     |    4 +
 gdb/value.c                                        |   23 ++-
 39 files changed, 2231 insertions(+), 139 deletions(-)
 create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90
 create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame.exp
 create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-alloc-assoc.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-datatypes.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-datatypes.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-func.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-func.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-history.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-ptr-info.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-ptype-sub.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-ptype.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-sizeof.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-stride.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-stride.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-strings.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-strings.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-sub.f90
 create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub-arbitrary.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub-finish.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla-value.exp
 create mode 100644 gdb/testsuite/gdb.fortran/vla.f90
 create mode 100644 gdb/testsuite/gdb.mi/mi-vla-fortran.exp
 create mode 100644 gdb/testsuite/gdb.mi/vla.f90

-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2016-09-14 12:53 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <88072818E0A3D742B2B1AF16BBEC65A7263D8247@IRSMSX107.ger.corp.intel.com>
     [not found] ` <20160707095439.GA6792@host1.jankratochvil.net>
     [not found]   ` <88072818E0A3D742B2B1AF16BBEC65A7263D990E@IRSMSX107.ger.corp.intel.com>
     [not found]     ` <20160714182743.GA10672@host1.jankratochvil.net>
     [not found]       ` <88072818E0A3D742B2B1AF16BBEC65A7263E6F2E@IRSMSX107.ger.corp.intel.com>
     [not found]         ` <20160715091352.GA8059@host1.jankratochvil.net>
     [not found]           ` <88072818E0A3D742B2B1AF16BBEC65A7263E8FD9@IRSMSX107.ger.corp.intel.com>
     [not found]             ` <20160716151310.GA14331@host1.jankratochvil.net>
     [not found]               ` <20160716151837.GA797@host1.jankratochvil.net>
     [not found]                 ` <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com>
2016-08-16 13:59                   ` [V4 00/21] Fortran dynamic array support Jan Kratochvil
2016-08-19  9:58                     ` Bernhard Heckel
2016-08-21 17:04                       ` Jan Kratochvil
2016-08-23 13:34                         ` Bernhard Heckel
2016-08-25 17:06                           ` Jan Kratochvil
2016-08-25 17:22                             ` Jan Kratochvil
2016-08-26  7:17                               ` Jan Kratochvil
2016-09-01 10:11                                 ` Bernhard Heckel
2016-09-02 13:44                             ` Bernhard Heckel
2016-09-04 17:15                               ` Jan Kratochvil
2016-09-07 10:29                                 ` Bernhard Heckel
2016-09-07 20:05                                   ` Jan Kratochvil
2016-09-12 21:05                                   ` Jan Kratochvil
2016-09-14  7:24                                     ` Bernhard Heckel
2016-09-14 12:53                                       ` Jan Kratochvil
2016-09-07 20:24                                 ` Jan Kratochvil
2016-09-01  9:48                           ` Jan Kratochvil
2015-01-14 13:49 Keven Boell
2015-05-28 20:36 ` Jan Kratochvil
2015-05-28 20:52   ` Joel Brobecker
2015-06-14  8:15 ` Jan Kratochvil
2015-06-17 11:42   ` Boell, Keven
2015-07-01 12:43     ` Keven Boell
2016-07-07  8:30 ` Jan Kratochvil
2016-07-07  9:16   ` Bernhard Heckel
2016-07-07  9:23     ` Jan Kratochvil

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).