fortran multidimensional arrays and pointers

fortran multidimensional arrays and pointers

[Mathew Yeates]

Hi
I see that multidimensional arrays are working fine. But I have a weird datatype

double precision, dimension(:,:), pointer :: coefs

and if I try and print
state%instrument%ils(num)%coefs(1,1)

I get incorrect values. (I also tried
*(state%instrument%ils(num)%coefs(1,1)) but that didn't work either.

Are fortran pointers supported?

Mathew

Re: fortran multidimensional arrays and pointers

[Tom Tromey]

>>>>> "Mathew" == Mathew Yeates <mat.yeates@gmail.com> writes:

Mathew> Are fortran pointers supported?

I don't know, but could you file a report in bugzilla with your example
and what you expected to happen?

Tom

Re: fortran multidimensional arrays and pointers

[Mathew Yeates]

Here is a very simple example
-----------------------------------------
      program bug
      integer , pointer,dimension(:) :: some_ints
      allocate (some_ints(1:10))
      some_ints(1) = 1
      some_ints(2) = 2
      write(*,*) some_ints(1)
      write(*,*) some_ints(2)
      end program bug
------------------------------------------
The program prints out '1','2'
but in gdb
#gdb bug
>b 6
>run
>print some_ints(1)
0
>print some_ints(2)
-1
>quit

On Mon, Feb 7, 2011 at 8:22 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Mathew" == Mathew Yeates <mat.yeates@gmail.com> writes:
>
> Mathew> Are fortran pointers supported?
>
> I don't know, but could you file a report in bugzilla with your example
> and what you expected to happen?
>
> Tom
>

Re: fortran multidimensional arrays and pointers

[Jan Kratochvil]

On Mon, 07 Feb 2011 19:48:02 +0100, Mathew Yeates wrote:
> >print some_ints(1)
> 0
> >print some_ints(2)
> -1

6	      write(*,*) some_ints(1)
(gdb) p some_ints(1)
$1 = 1
(gdb) p some_ints(2)
$2 = 2

It works on both:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	-> archer-jankratochvil-vla
and
	gdb-7.2-36.fc14 (Fedora 14)

That this archer branch is not yet merged in FSF GDB is another issue.


Regards,
Jan

Re: fortran multidimensional arrays and pointers

[Mathew Yeates]

Okay. I'll bite. Why is this not yet merged in FSF GDB? I find myself
using different versions of gdb depending on what I want to do.


-Mathew

On Mon, Feb 7, 2011 at 11:38 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 07 Feb 2011 19:48:02 +0100, Mathew Yeates wrote:
>> >print some_ints(1)
>> 0
>> >print some_ints(2)
>> -1
>
> 6             write(*,*) some_ints(1)
> (gdb) p some_ints(1)
> $1 = 1
> (gdb) p some_ints(2)
> $2 = 2
>
> It works on both:
>        http://sourceware.org/gdb/wiki/ArcherBranchManagement
>        -> archer-jankratochvil-vla
> and
>        gdb-7.2-36.fc14 (Fedora 14)
>
> That this archer branch is not yet merged in FSF GDB is another issue.
>
>
> Regards,
> Jan
>

Re: fortran multidimensional arrays and pointers

[Jan Kratochvil]

On Thu, 24 Feb 2011 20:32:51 +0100, Mathew Yeates wrote:
> Okay. I'll bite. Why is this not yet merged in FSF GDB?

That is why archer-jankratochvil-vla is not merged.

I have other bugs and other branches much easier to merge and they are also
not merged.  While I understand it is better for all the sides to merge them
these branches currently live in Fedora (and Archer) and if anyone needs the
functionality it is Freely available so I find other serious bugs as a more
urgent problem myself.

Specifically from http://sourceware.org/gdb/wiki/ArcherBranchManagement:

archer-jankratochvil-ifunc: This should get merged soon / these days, I hope
                            still for gdb-7.3.
archer-jankratochvil-watchpoint3: Upon Pedro's reply
  http://sourceware.org/ml/gdb-patches/2010-12/msg00348.html
  http://sourceware.org/ml/gdb-patches/2011-01/msg00561.html
  I find it now waiting on some merge of linux-nat and gdbserver code which
  seems to be continually being worked on by Yao Qi.  As I have other work to
  do I find it OK to just delay the merge after it.

There are other patches which are very small compared to VLA and which I would
also like to also merge, which suggest me they could be merged before VLA.
Some of them fix linux-nat which should be soon superseded by some form of
remote stub (gdbserver or ugdb or etc.). Which makes them a bit useless after
the switch but currently gdbserver is not a full replacement for linux-nat. It
is all related to the Yao's merges mentioned above.
	[patch 3/4]#3 linux-nat: Do not respawn signals
	http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html
	[patch] Fix syscall restarts for amd64->i386 biarch
	http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
	[patch] Fix hang on the thread leader exit
	http://sourceware.org/ml/gdb-patches/2007-07/msg00136.html
	SIGSTOP which need first an upstream kernel support discussed now on lkml.
	various other

archer-jankratochvil-vla:
The patches exist since Mar 2008, currently I believe most of the code should
be rewritten rather than merged.  There was an unsuccessful attempt to merge
it early and I later gave up on its merge and developed it rather maintainable
standalone.  Currently it became no longer meaningfully extensible as such
non-integrated add-on patches.

Currently the dynamic types to static types are converted during
check_typedef.  I believe check_typedef should be removed.  For storing
dynamic variables into convenience variables $foo there should just be stored
all the parts of memory needed to evaluate the dynamic bounds into `struct
value' (that is to support discontiguous value->contents).  In early VLA
patchset versions the macros accessing struct main_type evaluated the values
dynamically.

With check_typedef the GDB code is known to sometimes forget to call it.
Moreover with dynamic types sometimes one wants to call it only for a single
"type layer" (and no longer for its TYPE_TARGET_TYPE), in other cases one
wants to call it for the type and all its subtypes.

There were patches for type reference counting / garbage collecting - those
were needed for the check_typedef dynamic->static variant.  The types life
cycle management should not be needed for VLAs with dynamic check_typedef.

As with VLA even TYPE_HIGH_BOUND and other fields of main_type get runtime
modified no longer makes any distinction the struct type vs. struct main_type.
Therefore they should be merged.  struct type was separate so that it could be
modified as there was a limited number of its variants and so it does not
matter they can never be freed.  With proper life cycle managemement there can
be single struct type/main_type.

struct value needs to be simplified.  At least for lval_memory the fields like
OFFSET, ENCLOSING_TYPE, EMBEDDED_OFFSET and POINTED_TO_OFFSET cannot be used
as the memory accessed by the type is no longer contiguous anyway (value
address is a pointer to the descriptor where are contained the type's
boundaries and also pointer to the real data).

There should be provided some sharing of value->contents to make the code for
dereferencing each dimension simple and bug-free.  Fetching of the
discontiguous content can be made more by virtual methods with in-GDB cache,
where record_latest_value will fetch everything.

I wrote it just off the top of my head now without any patches but sure some
comments are welcome.


Thanks,
Jan

Re: fortran multidimensional arrays and pointers

[Tom Tromey]

Jan> Some of them fix linux-nat which should be soon superseded by some
Jan> form of remote stub (gdbserver or ugdb or etc.). Which makes them a
Jan> bit useless after the switch but currently gdbserver is not a full
Jan> replacement for linux-nat.

While I think this is a good future direction, I would not delay any
patch while waiting for it to be finished.

Jan> archer-jankratochvil-vla:
Jan> The patches exist since Mar 2008, currently I believe most of the
Jan> code should be rewritten rather than merged.

Ouch.

Jan> Currently the dynamic types to static types are converted during
Jan> check_typedef.  I believe check_typedef should be removed.

I guess I can see how it could be done: replace all TYPE_* macros with
functions, and do the typedef indirection there.  Is that what you are
thinking, or do you have some other idea?

Jan> For storing dynamic variables into convenience variables $foo there
Jan> should just be stored all the parts of memory needed to evaluate
Jan> the dynamic bounds into `struct value' (that is to support
Jan> discontiguous value->contents).  In early VLA patchset versions the
Jan> macros accessing struct main_type evaluated the values dynamically.

It seems to me that once you assign to a convenience variable, you are
taking a snapshot of a particular instance of a VLA.  So, converting to
a statically-bounded type would be the right thing to do here.

Jan> There were patches for type reference counting / garbage collecting
Jan> - those were needed for the check_typedef dynamic->static variant.
Jan> The types life cycle management should not be needed for VLAs with
Jan> dynamic check_typedef.

FWIW this work still seems relevant; you can still leak types via
Python.  It isn't urgent since this only happens in relatively weird
scenarios.

Jan> As with VLA even TYPE_HIGH_BOUND and other fields of main_type get
Jan> runtime modified no longer makes any distinction the struct type
Jan> vs. struct main_type.  Therefore they should be merged.

I am not so sure about this.  Type variants also save memory.

Jan> There should be provided some sharing of value->contents to make
Jan> the code for dereferencing each dimension simple and bug-free.
Jan> Fetching of the discontiguous content can be made more by virtual
Jan> methods with in-GDB cache, where record_latest_value will fetch
Jan> everything.

Yeah.  I think we need to destroy val_print, and only have value_print
-- but keep finding tricks to avoid it since it is so much work.  Once
that is done, fully virtualizing struct value like this would not be so
hard (famous last words), and would also let us address lazily read
arrays at print time.

Tom

Re: fortran multidimensional arrays and pointers

[Jan Kratochvil]

On Thu, 03 Mar 2011 18:23:58 +0100, Tom Tromey wrote:
> Jan> Some of them fix linux-nat which should be soon superseded by some
> Jan> form of remote stub (gdbserver or ugdb or etc.). Which makes them a
> Jan> bit useless after the switch but currently gdbserver is not a full
> Jan> replacement for linux-nat.
> 
> While I think this is a good future direction, I would not delay any
> patch while waiting for it to be finished.

It is not about waiting but there may be needed some effort before they get
merged and then (with gdbserver/ugdb/...) the code gets dropped anyway.


> Jan> Currently the dynamic types to static types are converted during
> Jan> check_typedef.  I believe check_typedef should be removed.
> 
> I guess I can see how it could be done: replace all TYPE_* macros with
> functions, and do the typedef indirection there.  Is that what you are
> thinking, or do you have some other idea?

check_typedef does multiple things, and more of them in the VLA branch.

One of them in FSF GDB is to set TYPE_LENGTH - this could be dynamic.

In other cases the code may want to access either the TYPE_CODE_TYPEDEF layer
or the dereferenced one (possibly resolved from TYPE_IS_OPAQUE) etc.
Sometimes the code wants to know if the boundary is dynamic sometimes it wants
to know the resolved number.

In general I agree but I would need to start patching the code first.

BTW also most of the `struct type *' pointers need to be changed
to `struct value *' as dynamic types resolving for VLA depends on the object
address (DW_AT_object_pointer).  There is a global variable for it in the VLA
branch but a global variable is wrong by design causing various problems
there.


> It seems to me that once you assign to a convenience variable, you are
> taking a snapshot of a particular instance of a VLA.  So, converting to
> a statically-bounded type would be the right thing to do here.

Yes, it is the right thing but completely needless.  There is a need for
discontiguous value->contents (such as for multidimensional array slices) and
there is a need for dynamic type parameters resolution (to simplify the code
by removing check_typedef).  In such case there is already enough
functionality one does not need to implement the conversion to static types.
It remains to be an inappropriate performance optimization.


> Jan> As with VLA even TYPE_HIGH_BOUND and other fields of main_type get
> Jan> runtime modified no longer makes any distinction the struct type
> Jan> vs. struct main_type.  Therefore they should be merged.
> 
> I am not so sure about this.  Type variants also save memory.

We can do some benchmarks if you mean it seriously but such memory saving has
no relevant size to ever consider it.


> Yeah.  I think we need to destroy val_print, and only have value_print
> -- but keep finding tricks to avoid it since it is so much work.  Once
> that is done, fully virtualizing struct value like this would not be so
> hard (famous last words), and would also let us address lazily read
> arrays at print time.

Yes, this cleanup has multiple benefits.


Thanks,
Jan