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 

Possible bug

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



Joined: 18 May 2012
Posts: 471
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Wed Mar 24, 2021 1:30 pm    Post subject: Possible bug Reply with quote

The following code compiles and runs in FTN95 Ver 8.70. An alternative compiler rejects this code (correctly?) since i is not defined as an integer.

Code:
program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
real(kind=dp) :: x(1:n) = (/(i,i=1,n)/), y(1:n) = (/(i,i=1,n)/)   !FTN compiler does not identify that i has no declared type
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main


This variation to the code runs with both compilers:

Code:
program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
integer a
real(kind=dp) :: x(1:n) = (/(a,a=1,n)/), y(1:n) = (/(a,a=1,n)/)
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main


Removing the declaration of a as an integer, as in:

Code:
program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
real(kind=dp) :: x(1:n) = (/(a,a=1,n)/), y(1:n) = (/(a,a=1,n)/)
integer j
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main


produces with FTN95
Quote:
C:\Users\kenneth smith\Desktop\pl_pic_2\FreeFormat2.F95(4) : error 637 - Internal compiler error - floating point exception


Something strange is happening here.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Wed Mar 24, 2021 4:21 pm    Post subject: Reply with quote

Thanks Ken. I have made a note of this.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 471
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Wed Mar 24, 2021 7:59 pm    Post subject: Reply with quote

Paul,

Looking at this again, it appears as if the implied do loop in the array construct is “blind” to the IMPLICIT NONE statement and applies the default IMPLICIT REAL(A-H), INTEGER(I-N), REAL(O-Z), which could possibly explain the difference between the 1st and 3rd examples.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Thu Mar 25, 2021 7:52 am    Post subject: Reply with quote

Ken

The scope of the DO index in an implied DO loop ought to be limited to the current statement. This was the motivation for a recent fix to FTN95. I will need to check when this fix took place.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Mon Mar 29, 2021 3:40 pm    Post subject: Reply with quote

My understanding is that the following program should compile without error as is the case with the current FTN95. There is a false warning message which will be removed for the next release of FTN95.

Code:
program main
implicit none
integer, parameter :: dp=kind(1.d0), n = 5
integer j
real(kind=dp) :: x(1:n) = (/(i,i=1,n)/), y(1:n) = (/(i,i=1,n)/)
  do j = 1, n, 1
    print*, j, x(j), y(j)
  end do
end program main
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Mon Mar 29, 2021 4:24 pm    Post subject: Reply with quote

The internal compiler error has now been fixed for the next release of FTN95.

As a result the compiler will set the type of the variable A to the default INTEGER type.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 471
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Mar 29, 2021 5:23 pm    Post subject: Reply with quote

Thanks Paul,

I will be wary of this construction when sharing code with those using alternative compilers.
Back to top
View user's profile Send private message Visit poster's website
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