[Bug fortran/89365] Inquiry functions for assumed rank objects fail

anlauf at gmx dot de gcc-bugzilla@gcc.gnu.org
Tue Feb 19 20:50:00 GMT 2019


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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #2 from Harald Anlauf <anlauf at gmx dot de> ---
The issue is probably not the LBOUND intrinsic, but the proper argument
association of the dummy argument of the subroutines.  (There is at least
another PR regarding POINTER dummy arguments)

The sample code has:

    subroutine foo_1(this) 
      real(c_float) :: this(..)

My reading of the F2018 FDIS regarding this case:

15.5.2 Actual arguments, dummy arguments, and argument association

15.5.2.4 Ordinary dummy variables

(1) The requirements in this subclause apply to actual arguments
that correspond to nonallocatable nonpointer dummy data objects.

(17) An actual argument of any rank may correspond to an
 assumed-rank dummy argument. The rank and extents of the dummy
 argument are the rank and extents of the corresponding actual
 argument. The lower bound of each dimension of the dummy
 argument is equal to one. The upper bound is equal to the
 extent, except for the last dimension when the actual argument
 is assumed-size.

That appears to be OK.  Right?

For the POINTER dummy argument (foo_3):

    subroutine foo_3(this) 
      real(c_float), pointer :: this(..)

Again, F2018 FDIS:

15.5.2.3 Argument association

(5) A present pointer dummy argument that corresponds to a
  pointer actual argument becomes argument associated with that
  actual argument.

Here I'd expect that we should actually get the same as if a pointer
association had taken place, c.f. PR85868 (so this one could be a duplicate?)

Finally:

    subroutine foo_2(this)
      real(c_float), allocatable :: this(..)

I couldn't find an appropriate reference here, so somebody else may have
something to say.


More information about the Gcc-bugs mailing list