Hi!

Given the following reduced code, from a bigger test case that I'm
currently writing:

    program main
      use openacc
      implicit none

      integer, allocatable :: ar(:,:,:)
      logical :: l

      if (allocated (ar)) stop 10 ! just for illustration
      l = acc_is_present (ar)
      print *, l

    end program main

..., this results in a list of '-Wuninitialized' diagnostics (have not
checked if also bad/"unexpected" code gnerated), and from the
'*.original' dump it's clear where that's coming from:

    __attribute__((fn spec (". ")))
    void MAIN__ ()
    {
      struct array03_integer(kind=4) ar;
      logical(kind=4) l;

      ar.data = 0B;
      ar.dtype = {.elem_len=4, .rank=3, .type=1};
      if ((integer(kind=4)[0:] * restrict) ar.data != 0B)
        {
          _gfortran_stop_numeric (10, 0);
        }
      L.1:;
      {
        integer(kind=8) D.4260;
        integer(kind=8) D.4261;
        integer(kind=8) D.4262;
        integer(kind=8) D.4263;
        integer(kind=8) D.4264;
        integer(kind=8) D.4265;
        struct array03_integer(kind=4) parm.0;
        integer(kind=8) D.4272;
        integer(kind=8) D.4273;

        D.4260 = ar.dim[0].lbound;
        D.4261 = ar.dim[0].ubound;
        D.4262 = ar.dim[1].lbound;
        D.4263 = ar.dim[1].ubound;
        D.4264 = ar.dim[2].lbound;
        D.4265 = ar.dim[2].ubound;
        parm.0.span = 4;
        parm.0.dtype = {.elem_len=4, .rank=3, .type=1};
        parm.0.dim[0].lbound = 1;
        parm.0.dim[0].ubound = (1 - D.4260) + D.4261;
        parm.0.dim[0].stride = 1;
        D.4272 = ar.dim[1].stride;
        parm.0.dim[1].lbound = 1;
        parm.0.dim[1].ubound = (1 - D.4262) + D.4263;
        parm.0.dim[1].stride = NON_LVALUE_EXPR <D.4272>;
        D.4273 = ar.dim[2].stride;
        parm.0.dim[2].lbound = 1;
        parm.0.dim[2].ubound = (1 - D.4264) + D.4265;
        parm.0.dim[2].stride = NON_LVALUE_EXPR <D.4273>;
        parm.0.data = (void *) &(*(integer(kind=4)[0:] * restrict) 
ar.data)[((D.4260 - ar.dim[0].lbound) + (D.4262 - ar.dim[1].lbound) * D.4272) + 
(D.4264 - ar.dim[2].lbound) * D.4273];
        parm.0.offset = ~NON_LVALUE_EXPR <D.4272> - NON_LVALUE_EXPR <D.4273>;
        l = acc_is_present_array_h (&parm.0);
      }
    [...]

Note 'D.4260 = ar.dim[0].lbound;', etc., with these 'ar' fields not
having been initialized.

For reference, OpenACC 'acc_is_present' is implemented in
'libgomp/openacc.f90':

   [...]
     72 module openacc_internal
     73   use openacc_kinds
     74   implicit none
     75
     76   interface
   [...]
    360     function acc_is_present_array_h (a)
    361       logical acc_is_present_array_h
    362       type (*), dimension (..), contiguous :: a
    363     end function
   [...]
    508   end interface
    509
    510   interface
   [...]
    698     function acc_is_present_l (a, len) &
    699         bind (C, name = "acc_is_present")
    700       use iso_c_binding, only: c_int32_t, c_size_t
    701       !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
    702       integer (c_int32_t) :: acc_is_present_l
    703       type (*), dimension (*) :: a
    704       integer (c_size_t), value :: len
    705     end function
   [...]
    760   end interface
    761 end module openacc_internal
    762
    763 module openacc
    764   use openacc_kinds
    765   use openacc_internal
    766   implicit none
    767
    768   private
   [...]
    793   public :: [...], acc_is_present
   [...]
    961   interface acc_is_present
    962     procedure :: acc_is_present_32_h
    963     procedure :: acc_is_present_64_h
    964     procedure :: acc_is_present_array_h
    965   end interface
   [...]
   1006 end module openacc
   [...]
   1413 function acc_is_present_array_h (a)
   1414   use openacc_internal, only: acc_is_present_l
   1415   logical acc_is_present_array_h
   1416   type (*), dimension (..), contiguous :: a
   1417   acc_is_present_array_h = acc_is_present_l (a, sizeof (a)) /= 0
   1418 end function
   [...]

GCC currently implements OpenACC 2.6,
<https://www.openacc.org/sites/default/files/inline-files/OpenACC.2.6.final.pdf>,
which in 3.2.30. "acc_is_present" states:

    *Summary* The 'acc_is_present' routine tests whether a host variable or 
array region is present
    on the device.

    *Format*
    C or C++:
        int acc_is_present( h_void*, size_t );
    Fortran:
        logical function acc_is_present( a )
        logical function acc_is_present( a, len )
         type(*), dimension(..) :: a
         integer :: len

    *Description* The 'acc_is_present' routine tests whether the specified host 
data is present
    on the device. In C, the arguments are a pointer to the data and length in 
bytes; the function
    returns nonzero if the specified data is fully present, and zero otherwise. 
In Fortran, two forms are
    supported. In the first, the argument is a contiguous array section of 
intrinsic type. In the second,
    the first argument is a variable or array element and the second is the 
length in bytes. The function
    returns '.true.' if the specified data is fully present, and '.false.' 
otherwise. If the byte length is
    zero, the function returns nonzero in C or '.true.' in Fortran if the given 
address is present at all
    on the device.

I may certainly be wrong on that -- still not too much of a Fortran
programmer... ;'-| -- but just like an "inquiry function"
'if (allocated (ar))', I would have expected 'acc_is_present (ar)' to
also work fine on un-allocated data (act as if called with a C/C++ 'NULL'
pointer).  Well, and maybe that's even what's happening, but there's the
'len' calculation that's firing here.  Should that one simply be put into
'if (ar.data != NULL)', and 'else' calculate a length of zero?

So, is the problem (a) in the user code, (b) in the GCC implementation --
and/or (c) in the OpenACC specification even?


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Reply via email to