Bug 844959

Has the testcase ever worked right with any gcc/gdb combination?  From what I can see, the IMHO right debug info is provided by all of 4.4-RH, 4.7-RH and 4.8, namely that istart is in the outer function (correct) when inside of the OpenMP region, and that transforms the problem from the Fortran common issue to something like:
int
main ()
{
  static int i;
  int j = 1;
  int k;
  #pragma omp parallel num_threads(2)
  {
    k = 2;
    __builtin_printf ("%d\n", k);
  }
  return 0;
}
where one would also expect to be able to print i and j while in the OpenMP region.  I guess we should eventually change the OpenMP generated code to call the body function directly even in the initial thread, then we can do magic with the backtrace.

Hmm.  It "works" e.g. on RHEL5 with 
libgomp-4.4.6-3.el5.1
gdb-7.0.1-42.el5
gcc-4.1.2-52.el5
gcc-gfortran-4.1.2-52.el5
also with 
gcc44-4.4.6-3.el5.1
gcc44-gfortran-4.4.6-3.el5.1

and also on RHEL6 (libgomp is essentially the same).

What the test does is basically

# cat tpcommon-init.f
      program correct
      use omp_lib
      integer iarray(100), N, nthreads, iam, chunk, istart, iend
      common /bounds/ istart, iend
!$omp threadprivate(/bounds/)

      N = 100
      istart = 1
!$omp parallel private(nthreads, iam, chunk)

      ! Compute the subset of iterations executed by each thread
      nthreads = omp_get_num_threads()
      iam = omp_get_thread_num()
      chunk = (N + nthreads - 1)/nthreads
      istart = iam * chunk + 1
      iend = min((iam + 1) * chunk, N)
      print *, nthreads, iam, chunk, istart, iend

      call work(iarray)
!$omp end parallel
      print *
      print *, iarray
      PRINT *, "Hello, World."
      end

      subroutine work(iarray)

      ! Subroutine to operate on a thread's portion of the array "iarray"
      integer iarray(100), istart, iend, i
      common /bounds/ istart, iend
!$omp threadprivate(/bounds/)

      do i = istart, iend
          iarray(i) = i * i
      enddo
      return
      end

# gfortran -fopenmp -g -O0 -o tpcommon-init tpcommon-init.f
then in
# gdb ./tpcommon-init
b 30
b 26
r
n
c
p istart

and checks whether at this point we don't get
"No symbol "istart" in current context."

It's possible that the test is flawed, I think it'd be better to use the C testcase in the first place, but I didn't write this one.  It just began to fail on RHEL7.

(Or it is a GDB bug.)

Argh, actually with abovementioned it works even on F16, but with this testcase it shows "No symbol "istart" in current context.":

! "Parallel Programming in OpenMP" ISBN 1-55860-671-8
! Copyright 2001 by Academic Press
! Example 4.7 (pp 104-105) with slight modifications

! AIX:
!   xlf90    -qsmp=noopt -g -O0 -o tpcommon_64_xlf90_9.1.0.3-qsmp=noopt-g-O0 \
!     tpcommon.f
!
! Linux x86:
!   pgf95    -mp         -g -O0 -o tpcommon_pgf95_6.2-3-mp-g-O0              \
!     tpcommon.f
!   gfortran -fopenmp    -g -O0 -o tpcommon_gfortran tpcommon.f
!   ifort    -openmp     -g -O0 -o tpcommon_ifort_10.0.013-openmp-g-O0       \
!     tpcommon.f
!   pathf90  -mp         -g -O0 -o tpcommon_pathf90_2.5-mp-g-O0              \
!     tpcommon.f
!   setenv PSC_OMP_STACK_SIZE 100000

      program correct
      use omp_lib
      integer iarray(100), N, nthreads, iam, chunk, istart, iend
      common /bounds/ istart, iend
!$omp threadprivate(/bounds/)

      N = 100
      istart = 1
!$omp parallel private(nthreads, iam, chunk)

      ! Compute the subset of iterations executed by each thread
      nthreads = omp_get_num_threads()
      iam = omp_get_thread_num()
      chunk = (N + nthreads - 1)/nthreads
      istart = iam * chunk + 1
      iend = min((iam + 1) * chunk, N)
      print *, nthreads, iam, chunk, istart, iend

      call work(iarray)
!$omp end parallel
      print *
      print *, iarray
      PRINT *, "Hello, World."
      end

      subroutine work(iarray)

      ! Subroutine to operate on a thread's portion of the array "iarray"
      integer iarray(100), istart, iend, i
      common /bounds/ istart, iend
!$omp threadprivate(/bounds/)

      do i = istart, iend
          iarray(i) = i * i
      enddo
      return
      end

(In reply to comment #2)
> From what
> I can see, the IMHO right debug info is provided by all of 4.4-RH, 4.7-RH
> and 4.8, namely that istart is in the outer function (correct) when inside
> of the OpenMP region

With the C test case I see that the artificial function generated by
GCC doesn't have a DW_AT_name.
gdb claims that this attribute is required.  I think I agree, DWARF 4
section 3.3 seems pretty definite on this point.
So, gdb skips this function's DIEs.

If I hack around this in gdb, then it works ok:

Breakpoint 1, zardoz () at pr.c:9
9	    k = 2;
(gdb) info local
k = 0

Could GCC just emit a DW_AT_name here?  I'd somewhat prefer that
over a gdb hack.

I didn't try the fortran tests yet.

For the more general case I think we'd need a debuginfo extension.
It's tempting to try to use the nested function approach, with some
attribute saying "check other threads", or maybe a magic local that
points to the "main" thread... but then I think we'd also need a fix for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927

(In reply to comment #6)

> I didn't try the fortran tests yet.

The 'istart' problem seems to be because gdb's support
for common blocks is questionable.

Not sure if you test it with FSF or Fedora/RHEL GDBs, the latter have replaced support for Fortran common blocks.

(In reply to comment #8)
> Not sure if you test it with FSF or Fedora/RHEL GDBs, the latter have
> replaced support for Fortran common blocks.

Even with the common blocks patches applied, we don't see them in
the artificial function:

(gdb) up
#1  0x0000000000400d69 in zardoz () at f.f90:37
(gdb) p istart
No symbol "istart" in current context.

The problem here is that GCC doesn't emit a DW_TAG_common_block
in the artificial function.  But, I think this is just another instance
of the problem where only variables used in the body of the artificial
function are available there, since we aren't using a static link or
anything similar.

The common block patches for gdb are also incomplete:

(gdb) down
#0  work (iarray=...) at f.f90:51
(gdb) p istart
$4 = 51
(gdb) info common
Contents of F77 COMMON block 'bounds':
istart = <address of value unknown>
iend = <address of value unknown>

I haven't debugged this yet but it does seem weird that read_common_block
uses decode_locdesc.  In this case the location is an expression:

    <176>   DW_AT_location    : 10 byte block: e 0 0 0 0 0 0 0 0 e0 	(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

(In reply to comment #9)

> The common block patches for gdb are also incomplete:
> 
> (gdb) down
> #0  work (iarray=...) at f.f90:51
> (gdb) p istart
> $4 = 51
> (gdb) info common
> Contents of F77 COMMON block 'bounds':
> istart = <address of value unknown>
> iend = <address of value unknown>

I sent some patches for this upstream.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0320.html