Hi Thomas,

Am 27.09.21 um 14:07 schrieb Tobias Burnus:
While playing I stumbled over the fact that when allocating an array
with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset
to 1 and ubound set to 0.

I am not sure, whether I fully understand what you wrote. For:

   integer, allocatable :: a(:)
   allocate(a(4:-5))
   print *, size(a), size(a, dim=1), shape(a) ! should print the '0 0 0'
   print *, lbound(a, dim=1) ! should print '1'
   print *, ubound(a, dim=1) ! should print '0'

where the last line is due to F2018, 16.9.196, which has:

  'Otherwise, if DIM is present, the result has a value equal to the
   number of elements in dimension DIM of ARRAY.'

And lbound(a,dim=1) == 1 due to the "otherwise" case of F2018:16.9.109 LBOUND:
"Case (i): If DIM is present, ARRAY is a whole array, and either
  ARRAY is an assumed-size array of rank DIM or dimension DIM of
  ARRAY has nonzero extent, the result has a value equal to the
  lower bound for subscript DIM of ARRAY. Otherwise, if DIM is
  present, the result value is 1."

And when doing
   call f(a)
   call g(a)
with 'subroutine f(x); integer :: x(:)'
and 'subroutine g(y); integer :: y(..)'

Here, ubound == 0 due to the reason above and lbound is set to
the declared lower bound, which is for 'x' the default ("1") but
could also be 5 with "x(5:)" and for 'y' it cannot be specified.
For 'x', see last sentence of F2018:8.5.8.3. For 'y', I did not
find the exact location but it follows alongsize.

it appears that I managed to kill the related essential part of
my comment (fat fingers?).  So here is what I played with:

program p
  implicit none
! integer, allocatable :: x(:,:)
  integer, pointer     :: x(:,:)
  allocate (x(-3:3,4:0))
  print *, "lbound =", lbound (x)
  call sub (x)
contains
  subroutine sub (y)
!   integer, allocatable :: y(..)
    integer, pointer     :: y(..)
    print *, "size   =", size (y)
    print *, "shape  =", shape (y)
    print *, "lbound =", lbound (y)
    print *, "ubound =", ubound (y)
  end subroutine sub
end

Array x is deferred shape, as is the dummy y.
This prints:

 lbound =          -3           1
 size   =           0
 shape  =           7           0
 lbound =          -3           1
 ubound =           3           0

For some reason Intel prints different lbound for main/sub,
meaning that it is broken, but here it goes:

 lbound =          -3           1
 size   =           0
 shape  =           7           0
 lbound =          -3           4
 ubound =           3           3

So for the first dimension everything is fine, but for the
second dim, which has extent zero, my question is: what should
the lbound be?  1 or 4?

With BIND(C) applied to f and g, ubound remains the same but
lbound is now 0 instead of 1.

I haven't check the BIND(C) complications.
For "common" Fortran code, I looked at 9.7.1.2(1):

"When an ALLOCATE statement is executed for an array for which
 allocate-shape-spec-list is specified, the values of the lower bound
 and upper bound expressions determine the bounds of the array.
 Subsequent redefinition or undefinition of any entities in the bound
 expressions do not affect the array bounds. If the lower bound is
 omitted, the default value is 1. If the upper bound is less than the
 lower bound, the extent in that dimension is zero and the array has
 zero size."

It is the word "determine" in first sentence that made me stumble.
I am not saying that it is wrong to handle extent zero the way it
is done - using lower bound 1 and upper bound 0 - as the extent is
correct.  *If* that is the case, then I would consider gfortran having
a consistent quality of implementation, but not Intel...

Has the standard has changed in this respect?

I doubt it, but only looked at F2018 and not at older standards.


PS: I saw that we recently had a couple of double reviews. I think it is
useful if multiple persons look at patches, but hope that we do not
start requiring two reviews for each patch ;-)

That would certainly have a very adversary affect and terribly increase the spam^WPING rate...

Harald

Reply via email to