Variable a in modular foo is represented as __foo__a in the DWARF output.  So you can use "print __foo__a" to get the value of modular variable a.

[woodzltc@plinuxt2 ~]$ gdb -q ./modular
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) b modular.f90:7
Breakpoint 1 at 0x10001700: file modular.f90, line 7.
(gdb) r
Starting program: /home/woodzltc/modular

Breakpoint 1, MAIN__ () at modular.f90:7
7         a = 42.
Current language:  auto; currently fortran
(gdb) p __foo__a
$2 = 0
(gdb) n
8         print *,a
(gdb) p __foo__a
$3 = 42
(gdb)

To let gdb recognize 'a' directly, some trick in gdb might be needed.

(In reply to comment #1)
> To let gdb recognize 'a' directly, some trick in gdb might be needed.

I don't know if some trickery is needed, just we might need to emit something like what C++ does with it using statements.

There is support for Fortran module variables in DWARF3, see http://dwarf.freestandards.org/Dwarf3.pdf.

Unfortunately GDB doesn't seem to support this.

I think the gfortran part is fixed by PR 29635. The rest has to be solved in gdb. Other debugers seem to have also some problems, e.g. Intel's idb, cf.
http://gcc.gnu.org/ml/fortran/2008-08/msg00128.html

Is this a duplicate of PR 40040?

Things work now without variable renaming, but with it,
they sometimes don't work.  Adjusting subject.

ig25@linux-fd1f:~/Krempel/GDB> cat rename.f90
module foo                                   
  implicit none                              
  integer :: a_foo = 3                       
  integer :: b_foo = 4                       
end module foo                               

module bar
  use foo, only : b_bar => b_foo
  implicit none
end module bar

module baz
  implicit none
  integer :: c_baz = 5
end module baz

program main
  use foo, only : a_main => a_foo
  use bar, only : b_main => b_bar
  use baz,  c_main => c_baz
  implicit none
  print *, a_main
  print *, b_main
  print *, c_main
end program main
ig25@linux-fd1f:~/Krempel/GDB> gdb ./a.out
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 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-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ig25/Krempel/GDB/a.out...done.
(gdb) b MAIN__
Breakpoint 1 at 0x40075f: file rename.f90, line 22.
(gdb) r
Starting program: /home/ig25/Krempel/GDB/a.out
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.10.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/lib64/ld-2.10.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=a121943782877c885215a25513d6bf0bfb6b6723"
warning: the debug information found in "/usr/lib/debug//lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).

Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=a4762e3dc63d9d17b92a985d53410c4931774ebc"

Breakpoint 1, MAIN__ () at rename.f90:22
22        print *, a_main
Current language:  auto
The current source language is "auto; currently fortran".
(gdb) p a_main
$1 = 3
(gdb) p b_main
No symbol "b_main" in current context.
(gdb) p c_main
No symbol "c_main" in current context.
(gdb)

My impression is that this is a bug in GDB and not in GCC (cf. readelf output below). For the following program, the result is: myvar is not found and gdb prints the wrong variable of the two "var33": Namely, the renamed one from "mod" and not the one of "mod2". Using "mod::var33" and "mod2::var33" works as expected. 

14        print *, myvar
(gdb)
          33
15        print *, var33
(gdb)
         -42
16      end program test
(gdb) p var33
$1 = 33
(gdb) p myvar
No symbol "myvar" in current context. 



Test program:

module mod
  integer :: var11 = 11, var22 = 22, var33 = 33
end module mod

module mod2
  integer :: var33 = -42
end module mod2

program test
  use mod, myvar => var33
  use mod2 ! imports var33 == -42
  implicit none
  print *, var11  ! prints: 11
  print *, myvar  ! prints: 33
  print *, var33  ! prints: -42
end program test


Readelf looks as follows:

 [   12f]    subprogram
...
             sibling              (ref4) [   1a5]
 [   153]      imported_module
               decl_file            (data1) 1
               decl_line            (data1) 11
               import               (ref4) [   1a5]
 [   15a]      imported_module
               decl_file            (data1) 1
               decl_line            (data1) 10
               import               (ref4) [   1cb]
               sibling              (ref4) [   171]
 [   165]        imported_declaration
                 decl_file            (data1) 1
                 decl_line            (data1) 10
                 name                 (strp) "myvar"
                 import               (ref4) [   1d6]

GDB patch by Jan:
  http://sourceware.org/ml/gdb-patches/2011-06/msg00378.html

(In reply to comment #7)
> My impression is that this is a bug in GDB and not in GCC

Thus, the original problem has been fixed at some point. (I think it was Jakub's 
2008-08-29 commit.)

Any recent FSF gdb should should be able to print module variables using the <module>::<var> syntax - or directly the variable if one uses use-association. I am not sure whether 7.2 handles it already or whether the 7.3 (branched, to be released soon) is required. (Maybe 7.1 already did?)

Regarding the rename issue of comment 6: As written in comment 7/comment 8: That's a GDB issue for which a patch exists (to be committed in the next hours).

Thus, I close the PR now as FIXED. Please reopen - or fill a new PR with CCing me - if a related/new issue pops up.