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 

Code generation bug, FTN95 32-bit version 7.20

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Apr 12, 2016 2:46 am    Post subject: Code generation bug, FTN95 32-bit version 7.20 Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Apr 12, 2016 7:11 am    Post subject: Reply with quote

Thanks for this. I have logged it for investigation.
The good news is that it runs OK with FTN95 /64.
Back to top
View user's profile Send private message AIM Address
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Tue Apr 12, 2016 9:32 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Apr 12, 2016 4:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Apr 12, 2016 5:37 pm    Post subject: Reply with quote

Thanks for the extra information.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Tue May 17, 2016 4:00 pm    Post subject: Reply with quote

This bug has now been fixed for the next full release.
Back to top
View user's profile Send private message AIM Address
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Fri Jun 10, 2016 11:11 am    Post subject: Reply with quote

Paul,
Is this issue ubound() fixed in 8.00?
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Jun 10, 2016 11:24 am    Post subject: Reply with quote

No. The issue at the beginning of this thread has been fixed for the next release after 8.0.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support 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