This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug fortran/15209] New: ptype/whatis cannot resolve Fortran modulename
- From: "sanimir.agovic at intel dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 27 Feb 2013 14:02:33 +0000
- Subject: [Bug fortran/15209] New: ptype/whatis cannot resolve Fortran modulename
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15209
Bug #: 15209
Summary: ptype/whatis cannot resolve Fortran module name
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned@sourceware.org
ReportedBy: sanimir.agovic@intel.com
Classification: Unclassified
Created attachment 6906
--> http://sourceware.org/bugzilla/attachment.cgi?id=6906
[PATCH/RFC] fortran: add module names to the symbol table
Compile the reproducer with "gfortran -g -o mod mod.f90"
ptype/whatis on a Fortran module name yield the following message:
% gdb mod -batch -ex "ptype mod1"
No symbol "mod1" in current context.
Expected is something like:
type = module mod1
## Uncomplete patch
The attached patch adds Fortran module names to the symbol table and thus
produces the expected result. Jan Kratochvil pointed out that this patch
introduces a regression, reproduced by:
gdb mod -batch -ex 'b 13' -ex r -ex 'p mod2' -ex 'ptype mod2'
[...]
Attempt to use a type name as an expression
type = module mod2
Whereas the correct output is:
[...]
$1 = 50
type = integer(kind=4)
## References
http://sourceware.org/ml/gdb-patches/2013-02/msg00643.html
## Reproducer
module mod1
integer :: var_i = 1
integer :: mod2 = 50
end module mod1
module mod2
integer :: var_i = 2
end module mod2
subroutine sub1
use mod1
mod2 = 51
end
program module
call sub1
end
--
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.