forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

/ISO and /SIZE_ISO

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
davidb



Joined: 17 Jul 2009
Posts: 553
Location: UK

PostPosted: Fri Apr 20, 2018 11:14 am    Post subject: /ISO and /SIZE_ISO Reply with quote

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.

Code:

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

Code:

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

_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5419
Location: Salford, UK

PostPosted: Mon Apr 23, 2018 12:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5419
Location: Salford, UK

PostPosted: Mon Apr 23, 2018 3:57 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 553
Location: UK

PostPosted: Mon Apr 23, 2018 5:11 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
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?
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5419
Location: Salford, UK

PostPosted: Mon Apr 23, 2018 6:26 pm    Post subject: Reply with quote

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.?
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 553
Location: UK

PostPosted: Mon Apr 23, 2018 8:45 pm    Post subject: Reply with quote

Hi Paul.

It might be worth looking at our previous discussion here:

http://forums.silverfrost.com/viewtopic.php?t=3281

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:

Code:

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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1959
Location: Sydney

PostPosted: Tue Apr 24, 2018 1:57 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 553
Location: UK

PostPosted: Tue Apr 24, 2018 6:53 am    Post subject: Re: Reply with quote

JohnCampbell wrote:
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.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5419
Location: Salford, UK

PostPosted: Tue Apr 24, 2018 10:16 am    Post subject: Reply with quote

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))
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group