[Bug fortran/82895] New: An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables

["arjen.markus at deltares dot nl" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 82895
           Summary: An internal routine used in a parallel section
                    (OpenMP) does not get the values of thread-private
                    variables
           Product: gcc
           Version: 6.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arjen.markus at deltares dot nl
  Target Milestone: ---

Created attachment 42559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42559&action=edit
Sample program exhibiting the bug

Background:
I want to use OpenMP to parallellise a large DO-loop in one of my programs. Due
to the updates to the arrays that are involved and the patterns of in which the
updates occur in a sequential run, I can do that via a nested loop, thus
avoiding collisions - i.e. both array elements A(i) and A(j) are updated in a
single iteration, but by structuring the DO-loop in an outer one that is
parallellised and an inner one that is not, I avoid such collisions.

To avoid duplication of the code (I need two sets of DO-loops), I want to use
an internal routine.

The attached program fails as the loop variable j (thread-private) does not get
the right value inside the internal routine loop_body. If I change the
signature to pass j explicitly as an actual argument, all seems to work well.
There is no such problem for the shared arrays.

My preliminary conclusion is that such private variables are not passed
correctly to internal routines.

Sample output (intended: the number of iterations per thread):
$ ./chkloop_internal
           1      100000
           2           0
           3           0
           4           0
           5           0
           6           0
           7           0
           8           0

instead of a more evenly spread of the iterations over the threads - actually
because the index j has the value 0, the counting does not work at all.