/ISO and /SIZE_ISO

The intrinsic SIZE() returns a 64 bit value (KIND = 4) by default.

Using /ISO or /SIZE_ISO is supposed to change this to the default integer kind but this doesn't seem to work. It is always kind = 4.

Instead /ISO changes the default integer kind to 4. It seems it is changing the wrong kind value to get the match. Furthermore /ISO is supposed to imply /SIZE_ISO but they give different behavior. /SIZE_ISO doesn't do anything.

Have a look at this code and the results below.

program main
integer i
real a(5)
i = 0
a = (/1.0,2.0,4.0,3.0,0.0/)
print *,' size is kind ', kind(size(a))
print *,' default integer is kind ', kind(i)
end

Here are the results of the code above.

/ISO not used and /SIZE_ISO not used

integer default kind = 3 size returns integer(kind=4)

not ISO compliant but this is OK in this case

/ISO used

integer default kind = 4 size returns integer(kind=4)

ISO compliant

/ISO used and /DEFINT_KIND 3 used

integer default kind = 3 size returns integer(kind=4)

not ISO compliant

/SIZE_ISO used

integer default kind = 3 size returns integer(kind=4)

not ISO compliant

The non-compliant cases above means the following doesn't work

module foo
contains
function find_max(a, n)
integer :: n
real :: a(n)
real :: find_max
find_max = maxval(a)
end function find_max
end module foo

program main
use foo
real a(5)
a = (/1.0,2.0,4.0,3.0,0.0/)
print *, find_max(a, size(a))
end

This failure is no longer apparent now that the result of the combination of /ISO /64 has been changed (the default INTEGER KIND now stays at 3). As a result the final piece of code above will work post v8.30.

If you ask for kind(size(a)) then you will still get 4 (for 64 bits) even with /SIZE_ISO but the critical feature is that (when used as an argument) its KIND becomes 3.

Further to my last post on this thread...

Up to and including v8.30, /ANSI was an exact alias for /ISO.

Now, users can use /ANSI (instead of /ISO) in order to also force the SIZE intrinsic to return an INTEGER of default kind in every context. So with /ANSI /64 (and without other options that change the default integer kind), kind(size(a)) will give the value 3, whilst /ANSI /DEFINT 4 will give kind(size(a)) is 4.

Quoted from PaulLaidler Further to my last post on this thread...

Up to and including v8.30, /ANSI was an exact alias for /ISO.

Now, users can use /ANSI (instead of /ISO) in order to also force the SIZE intrinsic to return an INTEGER of default kind in every context. So with /ANSI /64 (and without other options that change the default integer kind), kind(size(a)) will give the value 3, whilst /ANSI /DEFINT 4 will give kind(size(a)) is 4.

By 'Now' I assume you mean from the next release?

Thanks for the change to /ANSI. Will there also be a complimentary /SIZE_ANSI as well? Can you confirm that other functions, like UBOUND will be covered by these options?

Yes 'now' means the next release of FTN95 after v8.30.

I can't think of a reason for adding /SIZE_ANSI.

Can you give me an example of the potential impact on UBOUND etc.?

Hi Paul.

It might be worth looking at our previous discussion here:

https://forums.silverfrost.com/Forum/Topic/2900

Originally there was the option /SIZE32 which changed the behaviour of SIZE, UBOUND and LBOUND so that the result was a 32 bit integer (Kind=3).

The name of this option was then changed /SIZE_ISO and I suggested you could make SIZE, UBOUND and LBOUND return whatever the default integer kind happened to be (usually 3 but might be changed by the user with /DEFINT_KIND).

Later you introduce the idea of making /ISO imply /SIZE_ISO. You have also allowed the use of the F2003 optional KIND= argument.

However, as I understand things now, /SIZE_ISO does not quite do this. What it does is modify the behaviour of SIZE to return a 32 bit integer (kind=3) when it is an actual argument of a function or subroutine call. For all other uses, SIZE returns a 64 bit integer (kind=4). You can get this special behaviour either by using /ISO or /SIZE_ISO.

What you have now done is use /ANSI to unconditionally make SIZE return a default integer kind (I think this is the 'best' option from a compliance point of view).

The functions SIZE, UBOUND and LBOUND are all connected. The identity SIZE=UBOUND - LBOUND + 1 should always be maintained. A trivial example of code where it is necessary to be careful about the kind returned from UBOUND, LBOUND is:

module setup

contains

   subroutine set_zero1(q, s)
      real, intent(out) :: q(*)
      integer, intent(in) :: s
      q(1:s) = 0.0
   end subroutine set_zero1

   subroutine set_zero(q, a, b)
      real, intent(out) :: q(*)
      integer, intent(in). optional :: a, b
      call set_zero1(q, b-a+1)
   end subroutine set_zero

end module setup

program anon
   use setup, only: set_zero
   real q(10)
   call set_zero(q,lbound(q), ubound(q))
end program anon

It seemed to me you might want to align the behaviours of SIZE, UBOUND and LBOUND.

I don't really understand why /ISO cannot be the same as the new /ANSI. I thought that all was required was for SIZE to return a 64 bit value by default (when /ISO isn't used). Users who need this functionality won't be using /ISO because they wouldn't have access to other extensions if they did.

I find this thread very annoying.

As someone who uses SIZE with /64, I don't want an intrinsic that returns integer overflow. I want SIZE to return useful information.

How about catering to us users of Fortran.

Quoted from JohnCampbell I find this thread very annoying.

As someone who uses SIZE with /64, I don't want an intrinsic that returns integer overflow. I want SIZE to return useful information.

How about catering to us users of Fortran.

It isn't my intention to annoy anyone. This thread is only asking if /ISO (or /ANSI) works properly when users want better compliance with the ISO standard. At the moment there are a few problems around this area that need fixing.

This compiler is flexible though. Users who don't need ISO compliance will, by default, continue to have a 64 bit size when /64 is used. That is the use case you want/need so integer overflows should not occur.

Hopefully this will all be resolved in the next release of FTN95 as follows.

/ANSI will cause SIZE, UBOUND and LBOUND to have default integer KIND unless the KIND is specified in the code. Otherwise /ANSI is the same as /ISO.

/ISO checks that the code conforms to the Fortran Standard in all respects except for that covered by /ANSI above.

/SIZE_ISO causes SIZE, UBOUND and LBOUND to have default integer KIND when these are used as an argument and when the KIND is not specified in the code.

Users may want to use /ANSI or /ISO when writing code that might be ported to third party compilers.

Users may need to use /SIZE_ISO when porting from 32 bits to 64 bits and where SIZE is called as an argument that is expected to have default INTEGER KIND. For example...

 CALL sub1(x,SIZE(x))