[Bug fortran/12044] Fortran indexing does not work

[Bug fortran/12044] Fortran indexing does not work

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12044

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-04-12
                 CC|                            |tromey at redhat dot com
     Ever Confirmed|0                           |1

--- Comment #6 from Tom Tromey <tromey at redhat dot com> 2013-04-12 17:27:40 UTC ---
This seems to work ok for me with Fedora 18 gfortran
and CVS HEAD gdb as of today.
Is there still a bug here for you?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/12044] Fortran indexing does not work

[sergiodj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12044

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |sergiodj at redhat dot com
         Resolution|---                         |OBSOLETE

--- Comment #7 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
Closing as OBSOLETE because of inactivity.  Feel free to reopen if it is still
an issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug fortran/12044] Fortran indexing does not work

[mat dot yeates at gmail dot com]

------- Additional Comments From mat dot yeates at gmail dot com  2010-09-29 21:48 -------
This behavior is not seen in GNU 
gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=12044

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug fortran/12044] Fortran indexing does not work

[mat dot yeates at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 14298 bytes --]


------- Additional Comments From mat dot yeates at gmail dot com  2010-09-22 23:22 -------
Subject: Re:  New: Fortran indexing does not work

There is an obvious error in the patch. Lines 2309-2311 read
for (i = ndimensions - 1; i > 0; --i)
	  offset_item =
	    array_size_array[i - 1] * offset_item + subscript_array[i - 1];

So offset_item  gets it's value from the first dimension. Anyone have
any idea what it's supposed to be?

Maybe instead of '=' it should be += ??

-Mathew

On Mon, Sep 20, 2010 at 2:04 PM, mat dot yeates at gmail dot com
<sourceware-bugzilla@sourceware.org> wrote:
> The following code was compiled with gfortran -g3 -gdwarf-2 try1.f90 -o try1.
> This gdb-7.2 with a patch applied (see the bottom of this post)
>
> -------------------code----------------
>
>      subroutine  foo(Num_tau, Num_mixture,Gridded_resid_mask)
>      logical, intent(out), dimension(Num_tau, Num_mixture) :: &
>           Gridded_resid_mask
>      Gridded_resid_mask(:,:) = .TRUE.
>      if (Gridded_resid_mask(4,4)) then
>           write(*,*)  'Boo'
>      endif
>      end
>
>      program goo
>      logical,  dimension(100,100) :: &
>           Gridded_resid_mask
>      call foo(100,100,Gridded_resid_mask)
>      end
> -----------------------code--------------
>
> here is my gdb session
> gdb try1
> (gdb) b try1.f90:5
> (gdb) run
> (gdb) set Gridded_resid_mask(4,4)=.FALSE.
> (gdb) n
> 6                  write(*,*)  'Boo'
> (gdb) quit
>
> here is a session that works
>
> gdb try1
> gdb) b try1.f90:5
> run
> (gdb)p &Gridded_resid_mask
> $1 = (PTR TO -> ( logical(kind=4) (*,*))) 0x601280
> (gdb) set *(int)(0x601280 + 4*(3*100+3))=.FALSE.
> (gdb) n
> 8             end
> (gdb) quit
>
>
>
>
> ---The following patch was applied to 7.2------------
> diff -rcp gdb-7.2-clean/gdb/ChangeLog gdb-7.2/gdb/ChangeLog
> *** gdb-7.2-clean/gdb/ChangeLog 2010-09-03 00:37:25.000000000 +0100
> --- gdb-7.2/gdb/ChangeLog       2010-09-07 22:58:01.229977481 +0100
> ***************
> *** 1,3 ****
> --- 1,13 ----
> + 2010-09-07 Andrew Burgess <aburgess@broadcom.com>
> +
> +       * valarith.c (value_subscripted_rvalue) Walk through
> +       multi-dimensional arrays to find the element type for the
> +       array. Allows the upper bound check to work with multi-dimensional
> +       arrays.
> +       * eval.c (evaluate_subexp_standard) Remove hack from
> +       multi_f77_subscript case now that multi-dimensional arrays are
> +       supported in valarith.c
> +
>  2010-09-02  Joel Brobecker  <brobecker@adacore.com>
>
>        * NEWS: Replace "Changes since GDB 7.1" by "Changes in GDB 7.2".
> diff -rcp gdb-7.2-clean/gdb/eval.c gdb-7.2/gdb/eval.c
> *** gdb-7.2-clean/gdb/eval.c    2010-07-07 17:15:15.000000000 +0100
> --- gdb-7.2/gdb/eval.c  2010-09-07 22:44:31.493976944 +0100
> *************** evaluate_subexp_standard (struct type *e
> *** 2296,2311 ****
>
>            subscript_array[nargs - i - 1] -= lower;
>
> !           /* If we are at the bottom of a multidimensional
> !              array type then keep a ptr to the last ARRAY
> !              type around for use when calling value_subscript()
> !              below. This is done because we pretend to value_subscript
> !              that we actually have a one-dimensional array
> !              of base element type that we apply a simple
> !              offset to. */
> !
> !           if (i < nargs - 1)
> !             tmp_type = check_typedef (TYPE_TARGET_TYPE (tmp_type));
>          }
>
>        /* Now let us calculate the offset for this item */
> --- 2296,2302 ----
>
>            subscript_array[nargs - i - 1] -= lower;
>
> !           tmp_type = check_typedef (TYPE_TARGET_TYPE (tmp_type));
>          }
>
>        /* Now let us calculate the offset for this item */
> *************** evaluate_subexp_standard (struct type *e
> *** 2316,2329 ****
>          offset_item =
>            array_size_array[i - 1] * offset_item + subscript_array[i - 1];
>
> -       /* Let us now play a dirty trick: we will take arg1
> -          which is a value node pointing to the topmost level
> -          of the multidimensional array-set and pretend
> -          that it is actually a array of the final element
> -          type, this will ensure that value_subscript()
> -          returns the correct type value */
> -
> -       deprecated_set_value_type (arg1, tmp_type);
>        return value_subscripted_rvalue (arg1, offset_item, 0);
>        }
>
> --- 2307,2312 ----
> diff -rcp gdb-7.2-clean/gdb/valarith.c gdb-7.2/gdb/valarith.c
> *** gdb-7.2-clean/gdb/valarith.c        2010-06-07 17:11:31.000000000 +0100
> --- gdb-7.2/gdb/valarith.c      2010-09-07 22:52:25.154057798 +0100
> *************** struct value *
> *** 193,199 ****
>  value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound)
>  {
>    struct type *array_type = check_typedef (value_type (array));
> !   struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type));
>    unsigned int elt_size = TYPE_LENGTH (elt_type);
>    unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
>    struct value *v;
> --- 193,208 ----
>  value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound)
>  {
>    struct type *array_type = check_typedef (value_type (array));
> !   struct type *elt_type = array_type;
> !
> !   /* Peel of the array indices until we reach the array element type */
> !   do {
> !     elt_type = TYPE_TARGET_TYPE(elt_type);
> !   }
> !   while ( TYPE_CODE(elt_type) == TYPE_CODE_ARRAY);
> !
> !   elt_type = check_typedef(elt_type);
> !
>    unsigned int elt_size = TYPE_LENGTH (elt_type);
>    unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
>    struct value *v;
>
> --
>           Summary: Fortran indexing does not work
>           Product: gdb
>           Version: 7.2
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P2
>         Component: fortran
>        AssignedTo: unassigned at sourceware dot org
>        ReportedBy: mat dot yeates at gmail dot com
>                CC: gdb-prs at sourceware dot org
>
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=12044
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>

------- Additional Comments From mat dot yeates at gmail dot com  2010-09-23 00:08 -------
Subject: Re:  New: Fortran indexing does not work

okay. I found something that causes a bad result.
Lines 2292 and 2293 both return values of 1 so the array sizes all
turn out to be 1. Obviously incorrect.

I have no idea how to fix this. Can anyone help?

-Mathew

On Wed, Sep 22, 2010 at 4:22 PM, Mathew Yeates <mat.yeates@gmail.com> wrote:
> There is an obvious error in the patch. Lines 2309-2311 read
> for (i = ndimensions - 1; i > 0; --i)
>          offset_item =
>            array_size_array[i - 1] * offset_item + subscript_array[i - 1];
>
> So offset_item  gets it's value from the first dimension. Anyone have
> any idea what it's supposed to be?
>
> Maybe instead of '=' it should be += ??
>
> -Mathew
>
> On Mon, Sep 20, 2010 at 2:04 PM, mat dot yeates at gmail dot com
> <sourceware-bugzilla@sourceware.org> wrote:
>> The following code was compiled with gfortran -g3 -gdwarf-2 try1.f90 -o try1.
>> This gdb-7.2 with a patch applied (see the bottom of this post)
>>
>> -------------------code----------------
>>
>>      subroutine  foo(Num_tau, Num_mixture,Gridded_resid_mask)
>>      logical, intent(out), dimension(Num_tau, Num_mixture) :: &
>>           Gridded_resid_mask
>>      Gridded_resid_mask(:,:) = .TRUE.
>>      if (Gridded_resid_mask(4,4)) then
>>           write(*,*)  'Boo'
>>      endif
>>      end
>>
>>      program goo
>>      logical,  dimension(100,100) :: &
>>           Gridded_resid_mask
>>      call foo(100,100,Gridded_resid_mask)
>>      end
>> -----------------------code--------------
>>
>> here is my gdb session
>> gdb try1
>> (gdb) b try1.f90:5
>> (gdb) run
>> (gdb) set Gridded_resid_mask(4,4)=.FALSE.
>> (gdb) n
>> 6                  write(*,*)  'Boo'
>> (gdb) quit
>>
>> here is a session that works
>>
>> gdb try1
>> gdb) b try1.f90:5
>> run
>> (gdb)p &Gridded_resid_mask
>> $1 = (PTR TO -> ( logical(kind=4) (*,*))) 0x601280
>> (gdb) set *(int)(0x601280 + 4*(3*100+3))=.FALSE.
>> (gdb) n
>> 8             end
>> (gdb) quit
>>
>>
>>
>>
>> ---The following patch was applied to 7.2------------
>> diff -rcp gdb-7.2-clean/gdb/ChangeLog gdb-7.2/gdb/ChangeLog
>> *** gdb-7.2-clean/gdb/ChangeLog 2010-09-03 00:37:25.000000000 +0100
>> --- gdb-7.2/gdb/ChangeLog       2010-09-07 22:58:01.229977481 +0100
>> ***************
>> *** 1,3 ****
>> --- 1,13 ----
>> + 2010-09-07 Andrew Burgess <aburgess@broadcom.com>
>> +
>> +       * valarith.c (value_subscripted_rvalue) Walk through
>> +       multi-dimensional arrays to find the element type for the
>> +       array. Allows the upper bound check to work with multi-dimensional
>> +       arrays.
>> +       * eval.c (evaluate_subexp_standard) Remove hack from
>> +       multi_f77_subscript case now that multi-dimensional arrays are
>> +       supported in valarith.c
>> +
>>  2010-09-02  Joel Brobecker  <brobecker@adacore.com>
>>
>>        * NEWS: Replace "Changes since GDB 7.1" by "Changes in GDB 7.2".
>> diff -rcp gdb-7.2-clean/gdb/eval.c gdb-7.2/gdb/eval.c
>> *** gdb-7.2-clean/gdb/eval.c    2010-07-07 17:15:15.000000000 +0100
>> --- gdb-7.2/gdb/eval.c  2010-09-07 22:44:31.493976944 +0100
>> *************** evaluate_subexp_standard (struct type *e
>> *** 2296,2311 ****
>>
>>            subscript_array[nargs - i - 1] -= lower;
>>
>> !           /* If we are at the bottom of a multidimensional
>> !              array type then keep a ptr to the last ARRAY
>> !              type around for use when calling value_subscript()
>> !              below. This is done because we pretend to value_subscript
>> !              that we actually have a one-dimensional array
>> !              of base element type that we apply a simple
>> !              offset to. */
>> !
>> !           if (i < nargs - 1)
>> !             tmp_type = check_typedef (TYPE_TARGET_TYPE (tmp_type));
>>          }
>>
>>        /* Now let us calculate the offset for this item */
>> --- 2296,2302 ----
>>
>>            subscript_array[nargs - i - 1] -= lower;
>>
>> !           tmp_type = check_typedef (TYPE_TARGET_TYPE (tmp_type));
>>          }
>>
>>        /* Now let us calculate the offset for this item */
>> *************** evaluate_subexp_standard (struct type *e
>> *** 2316,2329 ****
>>          offset_item =
>>            array_size_array[i - 1] * offset_item + subscript_array[i - 1];
>>
>> -       /* Let us now play a dirty trick: we will take arg1
>> -          which is a value node pointing to the topmost level
>> -          of the multidimensional array-set and pretend
>> -          that it is actually a array of the final element
>> -          type, this will ensure that value_subscript()
>> -          returns the correct type value */
>> -
>> -       deprecated_set_value_type (arg1, tmp_type);
>>        return value_subscripted_rvalue (arg1, offset_item, 0);
>>        }
>>
>> --- 2307,2312 ----
>> diff -rcp gdb-7.2-clean/gdb/valarith.c gdb-7.2/gdb/valarith.c
>> *** gdb-7.2-clean/gdb/valarith.c        2010-06-07 17:11:31.000000000 +0100
>> --- gdb-7.2/gdb/valarith.c      2010-09-07 22:52:25.154057798 +0100
>> *************** struct value *
>> *** 193,199 ****
>>  value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound)
>>  {
>>    struct type *array_type = check_typedef (value_type (array));
>> !   struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type));
>>    unsigned int elt_size = TYPE_LENGTH (elt_type);
>>    unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
>>    struct value *v;
>> --- 193,208 ----
>>  value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound)
>>  {
>>    struct type *array_type = check_typedef (value_type (array));
>> !   struct type *elt_type = array_type;
>> !
>> !   /* Peel of the array indices until we reach the array element type */
>> !   do {
>> !     elt_type = TYPE_TARGET_TYPE(elt_type);
>> !   }
>> !   while ( TYPE_CODE(elt_type) == TYPE_CODE_ARRAY);
>> !
>> !   elt_type = check_typedef(elt_type);
>> !
>>    unsigned int elt_size = TYPE_LENGTH (elt_type);
>>    unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
>>    struct value *v;
>>
>> --
>>           Summary: Fortran indexing does not work
>>           Product: gdb
>>           Version: 7.2
>>            Status: UNCONFIRMED
>>          Severity: normal
>>          Priority: P2
>>         Component: fortran
>>        AssignedTo: unassigned at sourceware dot org
>>        ReportedBy: mat dot yeates at gmail dot com
>>                CC: gdb-prs at sourceware dot org
>>
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12044
>>
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.
>>
>

------- Additional Comments From mat dot yeates at gmail dot com  2010-09-23 17:29 -------
at line 2290 of gdb/eval.c , both "upper" and "lower" are set to the same value.
This is happening because, in the function f77_get_upperbound, the array upper
bound is undefined. According to the comments, this should only happen when we
have an assumed size array. But in the example i gave, the array size is known.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=12044

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug fortran/12044] Fortran indexing does not work

[mat dot yeates at gmail dot com]

------- Additional Comments From mat dot yeates at gmail dot com  2010-09-20 23:18 -------
I see the same behavior on an unpatched 7.2

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=12044

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.