public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* OpenACC 'acc_is_present' on un-allocated array: '-Wuninitialized' diagnostics
@ 2022-10-24 20:33 Thomas Schwinge
  2022-10-25 11:55 ` Tobias Burnus
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Schwinge @ 2022-10-24 20:33 UTC (permalink / raw)
  To: fortran, Tobias Burnus, Jakub Jelinek

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: OpenACC 'acc_is_present' on un-allocated array: '-Wuninitialized' diagnostics
  2022-10-24 20:33 OpenACC 'acc_is_present' on un-allocated array: '-Wuninitialized' diagnostics Thomas Schwinge
@ 2022-10-25 11:55 ` Tobias Burnus
  0 siblings, 0 replies; 2+ messages in thread
From: Tobias Burnus @ 2022-10-25 11:55 UTC (permalink / raw)
  To: Thomas Schwinge, fortran, Jakub Jelinek

Hi Thomas,

On 24.10.22 22:33, Thomas Schwinge wrote:
> Given the following reduced code, from a bigger test case that I'm
> currently writing:
>        integer, allocatable :: ar(:,:,:)
>        logical :: l
>        l = acc_is_present (ar)
> ...
>
>      360     function acc_is_present_array_h (a)
>      361       logical acc_is_present_array_h
>      362       type (*), dimension (..), contiguous :: a
>      363     end function

The function semantics for that function, provided by the interface, is
that that the array "a" has to exist, i.e. it has to be allocated.
Addionally, the 'contiguous' attribute also requires that the argument
is made contiguous. (Well, in this case it is a whole allocatable array
– those are known to be contiguous).

You could try to add an 'optional' attribute to 'a' – and check whether
it then works; I think it should, but I have now my lunch break and
cannot check.

optional = absent argument or unallocated allocatable or unassociated
pointer.

Tobias

-----------------
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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-10-25 11:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-24 20:33 OpenACC 'acc_is_present' on un-allocated array: '-Wuninitialized' diagnostics Thomas Schwinge
2022-10-25 11:55 ` Tobias Burnus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).