Problem with 64-bit FTN95 version 8.10

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]

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:

integer4 ifeld(ilav1) real4 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 real4 and real8 to overcome SOME of these problems, by changing the offset pointer : iflint, but you can't mix real4 and real8 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

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 

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.

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 real8 and/or integer8 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 real8 for FELD, DFELD and CRX and with the first compiler option '/defreal_kind 2' (in this case without real8 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

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

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

Compiled with /64, it gives

   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:

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

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:

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.

'/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.

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.

Additional info

Basic for the calculation: Shorter reproducer source code (see mecej4), [u:dc4e55a56a]but withou[/u:dc4e55a56a]t “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)+”integer8 iflint” + “real8 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

Many thanks for the additional feedback. That is very helpful. I have made a note that this needs fixing.

This bug has now been fixed for the next release of FTN95.