program struct REAL , POINTER :: RD(:,:) =>NULL() ALLOCATE(RD(10,10)) Compile with gfortran -g struct.f90 The Dwarf output for RD leads to: <1><10d>: Abbrev Number: 5 (DW_TAG_pointer_type) DW_AT_byte_size : 4 -- there should be a type in there (there is with most other compilers..) -- otherwise we have to interpret RD as Void* instead of double*.
Confirmed.
Works for me. Can you check with a recent 4.4 compiler? There I get: (idb) pt RD type = REAL(4)(10)(10) which looks OK.
With gdb on i686-apple-darwin9, I get either (gdb) pt rd type = real*4 (0:-1,0:-1) or (gdb) pt rd No symbol "rd" in current context.
Jakub, I think GCC sets the wrong type for "rd". It has: <1><1bb>: Abbrev Number: 7 (DW_TAG_array_type) <1bc> DW_AT_name : (indirect string, offset: 0xf9): array2_real(kind=4) whereas for ifort I get: <1><1fc>: Abbrev Number: 5 (DW_TAG_pointer_type) <1fd> DW_AT_type : <0x207> <201> DW_AT_associated : 5 byte block: 97 6 10 0 2e (DW_OP_push_object_address; DW_OP_deref; DW_OP_constu: 0; DW_OP_ne) <1><207>: Abbrev Number: 6 (DW_TAG_array_type) The DW_TAG_pointer_type and the DW_AT_associated should be there; gfortran has DW_AT_allocated which should not be there as there is no allocatable variable. Or do I miss something? My DWARF knowledge is limited. (In reply to comment #3) > With gdb on i686-apple-darwin9, I get either You know that gdb does not yet support variable-length arrays such as Fortran's assumed-shape arrays and C's (or was it C++'s?) VLA? This is work in progress (thanks, Jan!), see: http://sourceware.org/ml/gdb-patches/2008-10/msg00248.html http://people.redhat.com/jkratoch/vla/ Thus I was testing with the Intel Debugger (idb).
Has this been WAITING for 18 months now? Any news? :)
It IMHO shouldn't be DW_TAG_pointer_type, it is not a C style pointer. DW_TAG_array_type is what is emitted and what is listed in DWARF3/4 examples for Fortran code with POINTER variables. And current GCC certainly emits DW_AT_associated rather than DW_AT_allocated for POINTER vars. So I don't see any problem on the gfortran producer side.
(In reply to comment #6) > So I don't see any problem on the gfortran producer side. I take this as a suggestion to close this PR. Please reopen if misinterpreted.