|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1885
|
Posted: Tue Apr 12, 2016 2:46 am Post subject: Code generation bug, FTN95 32-bit version 7.20 |
|
|
A recent thread exposes, among other problems, a code generation bug. The code given in http://forums.silverfrost.com/viewtopic.php?t=3235&postdays=0&postorder=asc&start=0 is rather long. The arrays needed for the calculation are allocated in one subroutine and used in many other subroutines. The following stripped down example may look silly, but it captures the code generation bug.
Code: |
program tst
implicit none
integer, allocatable :: lnxt(:)
integer :: i, tot
!
tot = 10
allocate(lnxt(tot))
do i=1,tot
lnxt(i) = i+1
end do
lnxt(ubound(lnxt,1)) = 0 ! I don't write code like this, but it is still legit !
write(*,'(20I4)')lnxt
end program
|
Compiling and linking with the default options causes an access violation in one of the 60+ instructions generated by the line with the comment.
The bug may not be seen if the /debug or /opt compiler options are used.
Last edited by mecej4 on Tue Apr 12, 2016 11:30 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Apr 12, 2016 7:11 am Post subject: |
|
|
Thanks for this. I have logged it for investigation.
The good news is that it runs OK with FTN95 /64. |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Tue Apr 12, 2016 9:32 am Post subject: |
|
|
That is really good that it is taken up for further investigation.
But I like to include some more observations. Sometimes during run time, the array values show some unknown character values, in spite of its initialisation after its is allocated. This can be seen during step-in (F11) in debug mode. However, it shows the right values while printing.
I face this issue randomly, but can not be seen consistently. This may not be directly linked with UBOUND bug, but want to know the reasons for this. _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1885
|
Posted: Tue Apr 12, 2016 4:02 pm Post subject: |
|
|
Paul,
It is good to note that this bug does not occur with the 64-bit beta-3 compiler.
Here is some additional information that may help fix the bug.
I used the following modification of the test code:
Code: |
program tst
implicit none
integer, allocatable :: lnxt(:)
integer :: i, tot
!
tot = 10
allocate(lnxt(tot))
do i=1,tot
lnxt(i) = i+1
end do
call sub(lnxt)
write(*,'(20I4)')lnxt
contains
subroutine sub(ia)
integer :: ia(:)
ia(ubound(ia)) = 0
return
end subroutine
end program
|
This modification places the instruction causing the access violation to occur close to the subroutine entry, making it easier to locate and examine. With this code, the buggy code is emitted when /opt is used. I suspect that what happens is that, depending on the compiler options used, one assembly instruction gets lost. Here is the Exp-List portion near the entry to the contained subroutine (with some annotation added by me):
Code: |
; Start of SUBROUTINE TST~SUB
00000000(96/2/275) push ebp
00000001(97/2/275) mov ebp,esp
00000003(98/2/275) push ebx
00000004(99/2/275) push esi
00000005(100/2/275) push edi
00000006(101/2/275) push eax
00000007(102/2/275) sub esp,=24 ; Adjusted later if temporaries allocated
0000000d(103/2/275) mov ecx,address of IA
; Register ecx contains IA
; Register edx contains (IA:extent:1) ; ***NOT TRUE, here lies the bug ***
0013 AT 10
0014 contains AT 10
0015 subroutine sub(ia) AT 10
0016 integer :: ia(:) AT 10
00000010(106/6/270) lea eax,[edx-1] ; ***GARBAGE in EDX***
00000013(108/5/98) and eax,eax
00000015(109/5/98) jge __N9
0000001b(110/5/98) mov eax,=-1
00000020(111/5/98) Label __N9
00000020(112/5/98) mov (IA:size:1),eax
0017 ia(ubound(ia)) = 0 AT 23
00000023(113/6/126) mov esi,(IA:size:1)
00000026(114/6/126) inc esi
00000027(115/6/126) mov ArrayTemp@3,esi
0000002a(116/5/141) mov edi,ArrayTemp@3
0000002d(117/5/141) mov ArrayTemp@4,edi
00000030(118/6/274) mov eax,ArrayTemp@4
00000033(119/5/167) mov [ecx+eax*4-4],=0 ; *** ACCESS VIOLATION ***
|
The instruction that got left out, and should have been inserted after the instruction at offset 0000000D:
Code: |
mov edx,(IA:extent:1)
|
Last edited by mecej4 on Tue Apr 12, 2016 6:25 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Apr 12, 2016 5:37 pm Post subject: |
|
|
Thanks for the extra information. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue May 17, 2016 4:00 pm Post subject: |
|
|
This bug has now been fixed for the next full release. |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Fri Jun 10, 2016 11:11 am Post subject: |
|
|
Paul,
Is this issue ubound() fixed in 8.00? _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Fri Jun 10, 2016 11:24 am Post subject: |
|
|
No. The issue at the beginning of this thread has been fixed for the next release after 8.0. |
|
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
|