Hi Harald, hi all,
On 27.09.21 21:34, Harald Anlauf via Gcc-patches wrote:
[...] here is what I played with:
program p
implicit none
integer, pointer :: x(:,:)
allocate (x(-3:3,4:0))
print *, "lbound =", lbound (x)
call sub (x)
contains
subroutine sub (y)
integer, pointer :: y(..)
print *, "lbound =", lbound (y)
print *, "ubound =", ubound (y)
end subroutine sub
end
(Slightly shortened)
This prints:
lbound = -3 1
lbound = -3 1
ubound = 3 0
For some reason Intel prints different lbound
lbound = -3 1
lbound = -3 4
ubound = 3 3
First, that should be rather unrelated to my patch as here
the dummy argument is a pointer (could be also allocatable),
where the argument is passed through "as is".
For the latter reason, the expectation is that, both in the
caller and callee, the result is the same - which ifort's
result isn't.
Otherwise, the quote from F2018 of my previous email applies:
F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim'
argument the following. The case without 'dim' just iterates
through case (i) for each dim. Thus:
"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."
Here, we assume dim=2 is present [either directly or via case(ii)],
ARRAY is a whole array but it neither is of assumed size nor has nonzero
extent.
Hence, the "otherwise" applies and the result is 1 - as gfortran has
and ifort has in the caller.
The ubound then follows – there is a long list of conditions which
are all not fulfilled (you could check to confirm this) and
remaining is then only:
"Otherwise, if DIM is present, the result has a value equal to the
number of elements in dimension DIM of ARRAY."
And following your quote, there are zero elements in dim=2 of your
array. → ubound(…, dim=2) == 0.
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?
1
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.
There aren't real complications, except that with the C descriptor,
there is no lbound/ubound anymore but the descr->dim[i].lower_bound +
...[i].extent are directly referenced.
For GCC, the difference is that GCC uses lbound + ubound and CFI uses
lbound + extent. (The other difference is the use of stride in number of
elements vs. sm/stride multipler in number of bytes.)
The CFI array descriptor is IMHO more sensible than the GFC descriptor,
but for legacy reasons, we still carry it along.
For "common" Fortran code, I looked at 9.7.1.2(1):
...
It is the word "determine" in first sentence that made me stumble.
I think the Fortran standard does often not really tell what the bounds
are but just what lbound/ubound/size/shape produce. That's perfectly
fine – and permits different implementations in the background. (For C
interop, they had to specify, for obvious reasons, what's in the
descriptor itself.)
Cheers,
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
