Size intrinsic and related problems

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Size intrinsic and related problems

José Rui Faustino de Sousa
Hi all!

I noticed that the size intrinsic does not seem to follow the Fortran
standard, from my reading of it I would expect the following pseudo
Fortran to print -7:

arr(7,*)
call sub(arr)

subroutine sub(a)
a(..)

print *, size(a)

It prints 0.

In fact the size intrinsic will never return negative values as it is my
understanding the Fortran standard requires.

This seemed an easy thing to fix, but what is the protocol for "special"
arrays, like assumed size and zero sized arrays?

One possibility could be:

Zero sized   (arr(0)) lbound:1 ubound:0   so that extent is  0
Assumed-size (arr(*)) lbound:l ubound:l-2 so that extent is -1

This is likely documented somewhere, but I could not find it. And,
probably I am misunderstanding something, but usage in the code seems
inconsistent.

Then there is another related problem

arr(*)
call sub(arr(l:u))

subroutine sub(a)
a(..)

print *, size(a)

which again prints 0 and not u-l+1 has I expected.

This seems to be caused by the array section being explicitly marked as
an assumed-size array, by setting ubound to -1. I would expect the array
section to be passed as an explicit shape array, is my interpretation
correct?

If I understood correctly the meaning of the array types demanding that
the array type is AR_FULL would fix this, but OpenMP seems to need to
know if the section is from an assumed-size array...

The first point seems to be a clear bug report, but in order to try to
patch anything one would need an "official" position on the protocol to
use... The last one I am not positively sure if it is a bug and I have
no idea on how to pass the info to OpenMP.

Thank you very much.

Best regards,
José Rui
Reply | Threaded
Open this post in threaded view
|

Re: Size intrinsic and related problems

Steve Kargl
On Tue, Mar 03, 2020 at 10:50:23AM -0100, José Rui Faustino de Sousa wrote:
>
> I noticed that the size intrinsic does not seem to follow the Fortran
> standard, from my reading of it I would expect the following pseudo Fortran
> to print -7:
>

Need a minimum working example to understand what you think
you have observed.  In looking at your pseudo-code, it seems
to me that SIZE() can never return a negative value.  The
relevant wording from 16.9.179:

    Otherwise, the result has a value equal to the total number
    of elements of ARRAY.

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: Size intrinsic and related problems

Steve Kargl
On Tue, Mar 03, 2020 at 07:01:18AM -0800, Steve Kargl wrote:

> On Tue, Mar 03, 2020 at 10:50:23AM -0100, José Rui Faustino de Sousa wrote:
> >
> > I noticed that the size intrinsic does not seem to follow the Fortran
> > standard, from my reading of it I would expect the following pseudo Fortran
> > to print -7:
> >
>
> Need a minimum working example to understand what you think
> you have observed.  In looking at your pseudo-code, it seems
> to me that SIZE() can never return a negative value.  The
> relevant wording from 16.9.179:
>
>     Otherwise, the result has a value equal to the total number
>     of elements of ARRAY.
>

Nevermind.  Not enough coffee.  And, you pseudo-code was missing
leading to say the least.

--
steve
Reply | Threaded
Open this post in threaded view
|

Re: Size intrinsic and related problems

Tobias Burnus-3
In reply to this post by José Rui Faustino de Sousa
Hi José,

On 3/3/20 12:50 PM, José Rui Faustino de Sousa wrote:

> I noticed that the size intrinsic does not seem to follow the Fortran
> standard, from my reading of it I would expect the following pseudo
> Fortran to print -7:
> arr(7,*)
> call sub(arr)
>
> subroutine sub(a)
> a(..)
> print *, size(a)
> It prints 0.

Looks like a bug – and the result should be -7;
can you fill a bug report?

See "16.9.179  SIZE (ARRAY [, DIM, KIND])" in the Fortran 2018 standard,
https://j3-fortran.org/doc/year/18/18-007r1.pdf

"Result Value.
  If DIM is present, the result has a value equal to the extent
  of dimension DIM of ARRAY, except that if ARRAY is assumed-rank
  an associated with an assumed-size array and DIM is present
  with a value equal to the rank of ARRAY, the value is −1."

"If DIM is absent and ARRAY is assumed-rank, the result has a
  value equal to PRODUCT(SHAPE(ARRAY, KIND)). Otherwise, the result
  has a value equal to the total number of elements of ARRAY."

As the latter invokes "SHAPE" (15.9.172):

"Result Value.  The result has a value whose i-th element is equal to
  the extent of dimension i of SOURCE, except that if SOURCE is
  assumed-rank, and associated with an assumed-size array, the last
  element is equal to −1."

Cheers,

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Reply | Threaded
Open this post in threaded view
|

Re: Size intrinsic and related problems

José Rui Faustino de Sousa
On 03/03/20 14:13, Tobias Burnus wrote:
> can you fill a bug report?
>

Filled under:

Bug 94020 - Size, shape, possibly other intrinsics non standard conforming

and

Bug 94022 - Array slices of assumed-size arrays

But the main doubt I was hopping to have cleared is about what is the
protocol for passing assumed-size and zero sized arrays.

Different parts of the code seem to make different assumptions...

Thank you very much.

Best regards,
José Rui