|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Thu Mar 09, 2017 4:35 pm Post subject: 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] |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Fri Mar 10, 2017 1:37 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Fri Mar 10, 2017 10:45 am Post subject: |
|
|
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 |
|
|
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Fri Mar 10, 2017 9:05 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sat Mar 11, 2017 2:55 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Sat Mar 11, 2017 10:26 am Post subject: |
|
|
"/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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Sat Mar 11, 2017 11:34 am Post subject: |
|
|
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 |
|
|
wfgybgl
Joined: 28 Oct 2016 Posts: 8 Location: Bergisch Gladbach
|
Posted: Sat Mar 11, 2017 8:22 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Mar 13, 2017 8:49 am Post subject: |
|
|
Many thanks for the additional feedback. That is very helpful.
I have made a note that this needs fixing. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Mar 15, 2017 12:26 pm Post subject: |
|
|
This bug has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
|
|
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
|