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 

Compiler bug with /64 and /defint_kind 4

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
wfgybgl



Joined: 28 Oct 2016
Posts: 4

PostPosted: Mon Nov 14, 2016 4:47 pm    Post subject: Compiler bug with /64 and /defint_kind 4 Reply with quote

My modular program system (about 600 routines) works fine with the 32-bit version of FTN95.
In case of the 64-bit version (FTN95 compiler options: /64 /defint_kind 4) the results are completely wrong! An erroneous 64-bit execution could be localized and extracted in a small test program:

Silverfrost FTN95/WIN32 Ver 8.05.0 test-error.F90 Mon Nov 14 13:22:11 2016
Compiler Options in Effect:
64 COLOUR DEBUG DEFINT_KIND 4 DEFREAL_KIND 2 DELETE_OBJ_ON_ERROR LINK LIST
MINIMISE_REBUILD NO_QUIT NON_STANDARD SINGLE_THREADED

0001 program test
0002 integer, allocatable, dimension(:,:) :: iplate ! array for special plate type
0003 mxplate = 19
0004 ntypm = 4
0005 allocate(iplate(mxplate,0:ntypm))
0006 iplate = 0
0007
0008 iplate(10,2) = 2
0009
0010 write (6,*) 'Result: '
0011 write (6,*) 'Array iplate:'
0012 do j=0,ntypm
0013 write(6,'(20I3)') (iplate(i,j),i=1,mxplate)
0014 end do
0015
0016 write (6,*) 'Bit-size of iplate:', bit_size(iplate)
0017 write (6,*) ' '
0018 end

Result of test:
Array iplate:
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
Bit-size of iplate: 64

Instead of a single value at position (10,2), the entire column is filled with 2. In my opinion a compiler bug!

Remark: These small test program works fine with the 32-bit version and the 64-bit version with "integer*8, allocatable, dimension(:,:) :: iplate" (at line 2 of the code) instead of the compiler option /defint_kind 4.

Thanks
Wolfgang
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 14, 2016 5:12 pm    Post subject: Reply with quote

Wolfgang

The problem with "/defint_kind 4" is a known issue that has not yet been fixed.
For the time being, it is necessary to avoid this option and to use integer(7) or integer(4) locally where necessary.

In other words, don't change all integers to 64 bits but only change those that have to be changed.
Back to top
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 151

PostPosted: Thu Dec 28, 2017 6:34 pm    Post subject: Reply with quote

Is the /DEFINT_KIND 4 issue still outstanding? I have been trying to use UBOUND and LEN as subroutine arguments, and I saw from another post somewhere that some intrinsic functions are still defaulting to KIND=3 rather than 4, which would explain a compilation error message about wrong KIND. I can use UBOUND with a specified KIND parameter as a work-around, but that does not appear to be an option for LEN. I could use Int(Len(c), Kind=4), I suppose, but I was wondering what was the status of these two issues.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Dec 28, 2017 10:02 pm    Post subject: Reply with quote

Some of the problems with /DEFINT_KIND 4 have been fixed but it is probably not a good idea to use it anyway. Why use 64 bit integers globally? Why not just use them where needed?

Having said that, if you are able to report problems one at a time, illuatrated by a few lines of sample code, then we can progress through any remaining issues. In particular, do you have a few lines of code that illustrates the problem with UBOUND? Also what version of FTN95 are you using?
Back to top
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 151

PostPosted: Fri Dec 29, 2017 5:32 am    Post subject: Reply with quote

Here's some examples that generate a compile-time error using CheckMate x64:

Code:
Winapp
Program p1
  Integer :: iw
  Character(Len=16) :: c = 'ABCDEFGHIJKLMNOP'
! Len
  iw = winio$('%*ws', Len(c), c)
End Program p1

and
Code:
Program p2
  Integer, Dimension(2) :: a
! Ubound
  Call s (Ubound(a))
!
Contains
!
  Subroutine s (i)
   Integer, Intent(In) :: i
  End Subroutine s
!
End Program p2


I am using version 8.20.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1703
Location: Yateley, Hants, UK

PostPosted: Fri Dec 29, 2017 4:47 pm    Post subject: Reply with quote

“Why use 64 bit integers globally? Why not just use them where needed? “

Apart from the obvious riposte: “Why not?”, there is a traditional precedent,
which was that INTEGERs and the default REAL both had the same length. From the perspective of a programmer for whom programming is a sideline, not a main business, it is helpful if all integers have the same length, and you don’t need to check a range of overflow conditions.

On the other hand, INTEGER*8 is extremely wasteful of space for many purposes, and INTEGER*4 not much better. Take for example WINIO@. This function probably never returns other than 0, 1 or 2. Why does it have to be an INTEGER*4 function?

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Dec 29, 2017 6:07 pm    Post subject: Reply with quote

Simon

Code:
iw = winio$('%*ws', Len(c), c)


There are a number of different issues here that we need to fix.
In the meantime you will need to convert the KIND of LEN(c) as, for example, INT(LEN(c),3).
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Dec 29, 2017 6:22 pm    Post subject: Reply with quote

Simon

Code:
Call s (Ubound(a))


Again there are a number of issues here that need fixing.
In both these samples the problems are not primarily related to /DEFINT_KIND.
A work-around is to use s(int(Ubound(a),3)).
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 -> 64-bit 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