[Bug fortran/61014] New: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of derived data type array in nested subroutine

[Bug fortran/61014] New: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of derived data type array in nested subroutine

[sven.buijssen at math dot uni-dortmund.de]

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

            Bug ID: 61014
           Summary: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of
                    derived data type array in nested subroutine
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sven.buijssen at math dot uni-dortmund.de

(I am not exactly sure whether gfortran or gdb are to blame for this issue, but
I tend towards the former.)

The following causes gdb 7.4 to report missing symbols in current context when
compiled with recent gfortran versions:

$ cat <<EOF > debug.f90
program debug
  use module
  implicit none
  type(myint), dimension(1) :: bar
  call foo(bar)
end program debug
EOF
$ cat <<EOF > module.f90
module module
  implicit none
  type myint
    integer :: i = -1
  end type myint

contains
  subroutine foo(bar)
    type(myint), dimension(:) :: bar
    call subfoo()

  contains
    subroutine subfoo()
      bar(1)%i = 1
      print *, bar(1)%i
    end subroutine subfoo
  end subroutine foo
end module module
EOF
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gcc/4.9.0
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 (GCC)
$ gfortran -O0 -g -fno-inline -Wall -Wextra -c module.f90
$ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o
$ gdb --version
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
$ gdb a.out
(gdb) break module.f90:10
Breakpoint 1 at 0x4007a0: file module.f90, line 10.
(gdb) break module.f90:14
Breakpoint 2 at 0x400703: file module.f90, line 14.
(gdb) run
Starting program: /tmp/a.out 

Breakpoint 1, 0x00000000004007a0 in __module_MOD_foo ()
(gdb) print bar(1)%i
No symbol "bar" in current context.
(gdb) cont
Continuing.

Breakpoint 2, 0x0000000000400703 in subfoo.2335 ()
(gdb) print bar(1)%i
No symbol "bar" in current context.

#

Dito with GCC 4.8.2.

#

With GCC 4.6.3 and 4.7.3 the respective results of the two print commands in
gdb are:
$1 = -1
value has been optimized out

#

Whereas with GCC 4.4.7 and GCC 4.5.4 the very same version of gdb is able to
show the (expected) value of component i of the first entry of array "bar" at
both breakpoints:
$1 = -1
$2 = -1

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.5.4/libexec/gcc/x86_64-unknown-linux-gnu/4.5.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc/4.5.4
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.5.4 (GCC) 

###

With Intel Fortran 14.0.1.106 (aka XE 2013 SP1 Update 1) and its accompanying
debugger one can query the value always:

$ ifort -O0 -g -Warn all -c module.f90
$ ifort -O0 -g -Warn all -c debug.f90
$ ifort -O0 -g -Warn all debug.o module.o
$ idbc a.out
Intel(R) Debugger for applications running on Intel(R) 64, Version 13.0, Build
[80.483.23]
------------------ 
object file name: a.out 
Reading symbols from /tmp/a.out...done.
(idb) break module.f90:10
Breakpoint 1 at 0x402ca5: file /tmp/module.f90, line 10.
(idb) break module.f90:14
Breakpoint 2 at 0x402ce8: file /tmp/module.f90, line 14.
(idb) run
Starting program: /tmp/a.out
[New Thread 23410 (LWP 23410)]

Breakpoint 1, MODULE::foo (bar=(...)) at /tmp/module.f90:10
10          call subfoo()
(idb) print bar(1)%i
$1 = -1
(idb) cont
Continuing.

Breakpoint 2, subfoo () at /tmp/module.f90:14
14            bar(1)%i = 1
(idb) print bar(1)%i
$2 = -1
(idb) next
15            print *, bar(1)%i
(idb) print bar(1)%i
$3 = 1

[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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-30
          Component|fortran                     |debug
      Known to work|                            |4.5.4
            Summary|[4.6/4.7/4.8/4.9            |[4.7/4.8/4.9/4.10
                   |Regression] gdb can't find  |Regression] gdb can't find
                   |symbol of derived data type |symbol of derived data type
                   |array in nested subroutine  |array in nested subroutine
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I get (gdb 7.7):

Breakpoint 1, module::foo (bar=...) at module.f90:10
10          call subfoo()
(gdb) p bar
$1 = (( -1 ))
(gdb) p bar(1)%i
$2 = -1
(gdb) s
module::subfoo () at module.f90:14
14            bar(1)%i = 1
(gdb) p bar(1)%i
value being subranged must be in memory
(gdb) p bar
$3 = <optimized out>

seems that nested function lowering and debugging don't play well together.

Confirmed that it works well with 4.5.x.

[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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.4

[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]

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.)

[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]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #2)
> As you also have "idb" at hand

I now did it myself with gcc 4.10 and idbc 13.0. (I don't have ifort.)

Result:
In line 10, I get:
(idb) p bar
$3 = {i = -1}

but in line 14, I get:
`module::foo::subfoo () at /dev/shm/h4j.f90:14
14            bar(1)%i = 1
(idb) p bar
Info: symbol bar is defined but not allocated (optimized away)

Thus, as Richard wrote:
> seems that nested function lowering and debugging don't play well together.

[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

[sven.buijssen at math dot uni-dortmund.de]

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

--- Comment #4 from Sven Buijssen <sven.buijssen at math dot uni-dortmund.de> ---
I tried gdb 7.7 with Intel Fortran 10.1.023, 11.1.080, 12.1.7.367, 13.0.1.117,
13.1.3.192 and 14.0.2.144, respectively and get wrong results at breakpoint 1
(value of bar(1)%i = 0) and either "no symbol" or "cannot access memory" at
breakpoint 2:

ifort 10.1.023:
Breakpoint 1, MODULE::foo (bar=..., bar=...) at module.f90:10
10          call subfoo()
(gdb) p bar
$1 = (( 0 ))
(gdb) c
Continuing.

Breakpoint 2, 0x0000000000402af8 in modulefoo_mp_subfoo_ ()
(gdb) p bar
No symbol "bar" in current context.

#

ifort 11.1.080 & 12.1.7.367 & 13.0.1.117 & 13.1.3.192:
Breakpoint 1, MODULE::foo (bar=...) at module.f90:10
10          call subfoo()
(gdb) p bar
$1 = (( 0 ))
(gdb) c
Continuing.

Breakpoint 2, MODULE::subfoo () at module.f90:14
14            bar(1)%i = 1
(gdb) p bar
$2 = (( 0 ))
(gdb) p bar(1)%i
Cannot access memory at address 0x4

#

ifort 14.0.2.144:
Breakpoint 1, MODULE::foo (bar=...) at module.f90:10
10          call subfoo()
(gdb) p bar
$1 = (( 0 ))
(gdb) c 
Continuing.

Breakpoint 2, modulefoo_mp_subfoo_ () at module.f90:14
14            bar(1)%i = 1
(gdb) p bar
No symbol "bar" in current context.
(gdb) p bar(1)%i
No symbol "bar" in current context.

[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]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
For crossref, that was the patch r167201:
"[patch] Enable Ada bootstrap with LTO"
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02644.html

[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

[tromey at gcc dot gnu.org]

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

Tom Tromey <tromey at gcc dot gnu.org> changed:

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

--- Comment #7 from Tom Tromey <tromey at gcc dot gnu.org> ---
> seems that nested function lowering and debugging don't play well together.

Note that sometimes nested functions appear to work in gdb -- but
actually they do not, and if you get the right answer it is largely
just luck.  gdb ignores DW_AT_static_link. 
My attempt to make gdb understand this failed due to gcc bug #53927.


In this particular bug I am going to guess that the problem is the
use of non-constant array bounds in the DWARF, which gdb still
doesn't understand.  There's an ongoing project to fix this.

[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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

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

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug debug/61014] [9/10/11/12 Regression] gdb can't find symbol of derived data type array in nested subroutine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug debug/61014] [9/10/11/12 Regression] gdb can't find symbol of derived data type array in nested subroutine

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug debug/61014] [10/11/12/13 Regression] gdb can't find symbol of derived data type array in nested subroutine

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug debug/61014] [10/11/12/13 Regression] gdb can't find symbol of derived data type array in nested subroutine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug debug/61014] [11/12/13/14 Regression] gdb can't find symbol of derived data type array in nested subroutine

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.