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 

Problem with 64-bit FTN95 version 8.10

 
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: Thu Mar 09, 2017 4:35 pm    Post subject: Problem with 64-bit FTN95 version 8.10 Reply with quote

The following test program, extracted from my modular program system (for error/compiler bug(?) representation), is working fine with the 32-bit FTN95 version (8.10). Compiling with the 64-bit option it goes wrong, I cannot get my data back.
If 'iflint' is not listet in the COMMON /abrc2/, the 64-bit version works also correctly! But I need the option with these kind of values in the COMMON block!

Code and results:

program test2
c
common /abrc2/ iflint
c ****
c
parameter(ilav1=45000000)
common /rsy/ feld(ilav1)
dimension dfeld(ilav1),ifeld(ilav1)
equivalence(feld(1),ifeld(1))
equivalence(feld(1),dfeld(1))
c
iflint=3109312
lmaxd=ilav1
k1=35
nr=100010
c
call bleins (k1,nr,dfeld(iflint),lflint,lmaxd,6)
c ****
write (*,*) 'Daten in FELD:'
write (*,*) ( feld(iflint+i),i=0,15)
write (*,*) 'Daten in DFELD:'
write (*,*) (dfeld(iflint+i),i=0,15)
c
end program test2
c
c
subroutine bleins (inr,nr,crx,l,lmx,io)
dimension nr(32),crx(*)
write (io,*) 'inr:',INR
write (io,*) 'nr :',nr(1)
write (io,*) 'lmx:',lmx
c
l=28980
do i=1,l
crx(i)=4711.
end do
c
return
end subroutine bleins
c
c

32-bit compiling:
**************
inr: 35
nr : 100010
lmx: 45000000
Daten in FELD:
4711.00 4711.00 4711.00 4711.00 4711.00 4711.00 4711.00
4711.00 4711.00 4711.00 4711.00 4711.00 4711.00 4711.00
4711.00 4711.00
Daten in DFELD:
4711.00 4711.00 4711.00 4711.00 4711.00 4711.00 4711.00
4711.00 4711.00 4711.00 4711.00 4711.00 4711.00 4711.00
4711.00 4711.00

64-bit compiling:
**************

inr: 35
nr : 100010
lmx: 45000000
Daten in FELD:
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000
Daten in DFELD:
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000
0.00000000000 0.00000000000 0.00000000000 0.00000000000 [/b][/code]
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1834
Location: Sydney

PostPosted: Fri Mar 10, 2017 1:37 am    Post subject: Reply with quote

You have dimension nr(32) in subroutine bleins , but not in the main program. This could be causing some of the problems, although I don't get your reported /64 results.

I also included type declarations, as my Fortran environment defaults to IMPLICIT NONE

This appears to be an example of pre-F90 memory management, which only works the way you imply if the integer and real arrays are the same byte length.

I think that your problem in your original program may be related to " dimension dfeld(ilav1),ifeld(ilav1) " which I think is more likely to be:

integer*4 ifeld(ilav1)
real*4 feld(ilav1)
real*8 dfeld(ilav1/2)

In this case equivalence (feld(1),dfeld(1)) would not produce the results you claim, as the byte length of feld and dfeld are different.
There are ways of mixing real*4 and real*8 to overcome SOME of these problems, by changing the offset pointer : iflint, but you can't mix real*4 and real*8 values at the same memory address and expect to use them.
ALLOCATE is much better, but with legacy code it can be better to get the offset pointers correct.

John


Code:
program test2
!
 common /abrc2/ iflint
! ****
!
 parameter(ilav1=45000000)
 common /rsy/ feld(ilav1)
 dimension dfeld(ilav1),ifeld(ilav1)
 equivalence(feld(1),ifeld(1))
 equivalence(feld(1),dfeld(1))
!
!  error:1 implicit none conformance
 integer*4 i,iflint, ilav1,ifeld,lmaxd,k1,lflint
 real*4    feld,dfeld
!
!  error:2 nr is an array
 integer*4 nr(32)

 iflint=3109312
 lmaxd=ilav1
 k1=35
 nr=100010
!
 call bleins (k1,nr,dfeld(iflint),lflint,lmaxd,6)
! ****
 write (*,*) 'Daten in FELD:'
 write (*,*) ( feld(iflint+i),i=0,15)
 write (*,*) 'Daten in DFELD:'
 write (*,*) (dfeld(iflint+i),i=0,15)
!
 end program test2
!
!
 subroutine bleins (inr,nr,crx,l,lmx,io)

  integer*4 inr,nr,l,lmx,io, i
  real*4    crx
 
 dimension nr(32),crx(*)
 write (io,*) 'inr:',INR
 write (io,*) 'nr :',nr(1)
 write (io,*) 'lmx:',lmx
!
 l=28980
 do i=1,l
 crx(i)=4711.
 end do
!
 return
 end subroutine bleins
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 10, 2017 10:45 am    Post subject: Reply with quote

The program test2 runs correctly for me and I can't think of a reason why it fails on your machine.

Try stepping into the code using SDBG64 after compiling with /DEBUG.
Also try printing LOC(dfeld(iflint)) before calling bleins and comparing with LOC(crx) within bleins.
Back to top
View user's profile Send private message
wfgybgl



Joined: 28 Oct 2016
Posts: 4

PostPosted: Fri Mar 10, 2017 9:05 pm    Post subject: Reply with quote

John, Paul

I am very sorry, but the original programs with about 600 subroutines are very old, developed since 1970 (pre-F90 memory management, as you pointed out!). Some of them only work if the integer and real arrays have the same byte length. My test program test2 results from one of these codes. You are right, NR is an array. I have tested it with and without in the main program. The results are wrong in both cases.
I am working here exclusively with the compiler options ‘/defreal_kind 2’ and ‘/defint_kind 4’, not with real*8 and/or integer*8 statements (about 600 subroutines!!) See also my posting: Compiler bug with /64 and defint_kind 4, dated from Nov 14, 2016.
Current status:
TEST2 runs (/64) without these compiler options produce correct results! This is also the case with real*8 for FELD, DFELD and CRX and with the first compiler option '/defreal_kind 2' (in this case without real*8 xxx statements). Adding the second compiler option (/defint_kind 4) results in the known faulty behavior. My question: could there be still a problem of /defint_kind 4?

Wolfgang
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 739

PostPosted: Sat Mar 11, 2017 2:55 am    Post subject: Reply with quote

Here is a much shorter reproducer. Compiled with the default options with FTN95 8.10, it gives the correct output:
Code:

    1.000E+00   2.000E+00   3.000E+00   4.000E+00   5.000E+00

Compiled with /64, it gives
Code:

   0.000E+00   2.000E+00   0.000E+00  -1.084E-19   0.000E+00

The cause of the code generation bug is the appearance of iflint in a common block and its being an 8-byte integer:
Code:

00000026(#11,4):      MOV_Q     RBX,Address of /ABC/ Block 0
0000002d(#11,5):      MOV_Q     [RBX],1
00000039(#88,6):      MOV_Q     R15,[RBX]
00000041(#25,7):      LEA       RCX,FELD[R15-4]  ##<<<< BUG here ***
00000046(#26,8):      CALL      BLEINS

Without the common block, the code generated is
Code:

00000026(#9,4):      MOV_Q     IFLINT,1
0000002f(#23,5):      MOV_Q     RBX,IFLINT
00000034(#23,6):      LEA       RCX,FELD[4*RBX-4]
00000039(#24,7):      CALL      BLEINS

The source code of the reproducer:
Code:

program test2
   implicit none
   integer*8 :: iflint
   common /abc/ iflint
   real feld(10)

   iflint=1
   call bleins (feld(iflint))
   write (*,*) 'Daten in FELD:'
   write (*,'(10ES12.3)') feld(1:5)
end program test2

subroutine bleins (crx)
   implicit none
   real crx(*)
   crx(1:5)=[1,2,3,4,5]
   return
end subroutine bleins

Running this code in SDBG64 show up a bug in the debugger: place a breakpoint on the RETURN in the subroutine. When the breakpoint is hit, the variables pane shows CRX as "invalid" and with "subscripts out of bounds".

SDBG64 allows you only one run through the program, with no provision to stop the target program and restart.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Mar 11, 2017 10:26 am    Post subject: Reply with quote

"/defint_kind 4" is known to fail in some contexts so I recommend that you check that you really need it. If you do then perhaps you could restrict its use to those subprograms that really need it.

I will log this as a context in which this fails but for the time being the option should be used with caution.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 739

PostPosted: Sat Mar 11, 2017 11:34 am    Post subject: Reply with quote

Paul, the simplified test program that I posted does not need the use of /defint_kind or /defreal_kind to expose the bug, which seems to be related to the use of an 8-byte integer in a common block in 64-bit mode.
Back to top
View user's profile Send private message
wfgybgl



Joined: 28 Oct 2016
Posts: 4

PostPosted: Sat Mar 11, 2017 8:22 pm    Post subject: Reply with quote

Additional info

Basic for the calculation:
Shorter reproducer source code (see mecej4), but without “integer*8 iflint“ and “implicit none“. Compiled with /64 FTN95 8.10.0, default compiler options (without “defreal” and “defint”!!!).

(1) Basic configuration; →correct output
(2) (1)+”integer*8 iflint” + “real*8 feld + real*8 crx; →wrong output
(3) (2) without “common block /abc/ iflint”; →correct output
(4) (1) + compiler option “/defreal_kind 2”; →correct output
(5) (4) + compiler option “defint_kind 4”; →wrong output
(6) (5) without “common block /abc/ iflint”; →correct output
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Mar 13, 2017 8:49 am    Post subject: Reply with quote

Many thanks for the additional feedback. That is very helpful.
I have made a note that this needs fixing.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Mar 15, 2017 12:26 pm    Post subject: Reply with quote

This bug has now been fixed for the next release of FTN95.
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