[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Sven Buijssen from comment #0)
> (I am not exactly sure whether gfortran or gdb are to blame for this issue,
> but I tend towards the former.)

> $ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o
> $ gdb --version

> $ ifort -O0 -g -Warn all debug.o module.o
> $ idbc a.out

As you also have "idb" at hand: You could cross check whether the GCC/gfortran
binary works with idbc - and the ifort binary with gdb. They both use the same
debugging format (which can differ slightly between versions).


>  subroutine foo(bar)
>    type(myint), dimension(:) :: bar

This line implies that gfortran uses array descriptors; those are not yet
supported in GDB - except that some vendor's versions (e.g. Red Hat/Fedora and
(open)SUSE have some basic support.

There is an on-going effort to add arrays-descriptor support to GDB; the first
step, the support of C99's varying-length arrays has been added a few weeks ago
to the GDB trunk. The Fortran support is supposed to come next, but it still
will take a couple of weeks. See also:
https://github.com/intel-gdb/vla/branches - but the Fortran branch there is a
bit outdated.


However, ...

(In reply to Richard Biener from comment #1)
> I get (gdb 7.7):
...
> seems that nested function lowering and debugging don't play well together.
> Confirmed that it works well with 4.5.x.

The combination that it works with 4.5 and that also a SUSE-build of gdb shows
the problem, makes it more likely that the problem lies elsewhere.

(It might be still a combination of changed dwarf generation in GCC and
incomplete GDB support.)