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 

Optimizer bug in FTN95 7.10

 
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: Thu Apr 16, 2015 4:47 am    Post subject: Optimizer bug in FTN95 7.10 Reply with quote

The following short program demonstrates an optimizer bug that was first encountered in a ~800 line program.
Code:
      program tmb11
      implicit none
      double precision A(2,5)
      integer :: j,n=5
      DOUBLE PRECISION RMAX,RSUM
      INTRINSIC ABS
      data A/1d0,2d0,2d0,4d0,3d0,6d0,1d0,0d0,0d0,2d0/

      RMAX = 0.0D0
      RSUM = 0.0D0
      do j = 1, n
         RSUM = RSUM + a(1,j)**2
         if (RMAX >= ABS(a(1,j))) cycle
         RMAX = ABS(a(1,j))
      end do
      write(*,'(A,F4.1)')'RSUM = ',RSUM
      stop
      end

Compiled with /opt, the program gives the incorrect output
Code:
RSUM =  5.0

instead of the correct output, which is
Code:
RSUM =  15.0

P.S.: Paul, I have further narrowed down the location of the bug by looking at the assembly listing (see my post of Fri Apr 17, 2015 6:14 am, below). The optimized code calculates SUM(a(1,1)**2) instead of SUM(a(1,j)**2).

[Added 3 August 2015]: The bug is still present in the 7.20 compiler release.


Last edited by mecej4 on Mon Aug 03, 2015 12:41 pm; edited 2 times 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: Thu Apr 16, 2015 7:46 am    Post subject: Reply with quote

Thanks. I have logged this for investigation.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Apr 16, 2015 10:22 pm    Post subject: Reply with quote

Hi Mecej4,

If you write your code '77-style' does the optimizer work? I ask this, not to push a geriatric code agenda, but to pin down whether it is something introduced with new forms, or something that was always there.

I find FTN95 adequately fast for my purposes without /OPT, and I remember having problems with it some years ago, and so I stopped using the optimization. In truth it was when I was wrestling with a nonstandard dpi setting problem to do with toolbar icon spacing, and it may have had nothing to do with /OPT, but then one gets into habits that are difficult to change.

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Apr 16, 2015 11:25 pm    Post subject: Reply with quote

Optimizer bugs are quite fragile and, for that reason, hard to pin down. Small changes to the code , including changes in form (as you asked) and changes in syntax with no change in semantics, can make optimizer bugs active or dormant.

In my example, replacing the two statements containing RMAX in the DO loop by
Code:
RMAX = MAX(RMAX,ABS(a(1,j)))

makes the bug go away.

Old style code is less likely to run into optimizer problems simply because the compiler, having been applied to such code over more years, has had such bugs fixed. You may remember that very early Fortran 90 compilers produced such slow and buggy code that many users continued writing F77 for a few more years.

As a user, I think that I can live with /opt not speeding up the execution much, but I would not accept a situation where any option that is provided with a compiler has the effect of making a correct program work incorrectly -- Primum non nocere!
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Apr 17, 2015 12:51 am    Post subject: Reply with quote

Eddie,

Even the minor change to:
Code:
          if (RMAX < ABS(a(1,j)) ) RMAX = ABS(a(1,j))
removes the problem.

Also changing to F77 syntax does remove the problem as:
Code:
       do 10 j = 1, n
          RSUM = RSUM + a(1,j)**2
          if (RMAX >= ABS(a(1,j))) goto 10
          RMAX = ABS(a(1,j))
    10 continue

In this example, changing "goto 10" to "cycle" initiates the error. I think that a GOTO in a DO loop can restrict some optimising possibilities, even ones we don't want.

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Apr 17, 2015 1:14 pm    Post subject: Reply with quote

John's comments (Thu Apr 16, 2015 5:51) illustrate why cut down reproducers are necessary evils. With the trimmed down code, especially one with fewer than, say, twenty lines, we can conjure up many ways of changing the code and working around the optimizer bug, because we know precisely which lines are responsible. With real code wherein an optimizer bug is suspected, it can be quite difficult to (i) establish that there is an optimizer bug, and (ii) find the line(s) of code responsible. A symbolic debugger is not going to be of much help in doing this, because optimized code and a symbolic debugger do not get along well.

Note that, in this example, an insightful and capable optimizer could recognize that the variable RMAX and all lines of code containing RMAX could be optimized away, and the optimizer bug, which is triggered by those lines of removed code, would remain in hiding.

Here is an excerpt from the assembly listing that shows the bug. The only FMUL instruction in the entire listing has been moved ahead of the DO loop, which begins at offset 70H (disregard the annotations such as "AT 54", which give wrong offsets when /opt has been used). Thus, the "optimized" code computes the sum of a(1,1)**2, rather than the sum of a(1,j)**2.

Code:
      0000004d(24/5/154)         mov       Temp@3,=2
   0012            RSUM = RSUM + a(1,j)**2                                                       AT 54
      00000054(25/5/245)         mov       eax,Temp@3
      00000057(26/5/245)         dfld      A[eax*8-16]
      0000005e(27/5/245)         fmul      fr0,fr0
      00000060(28/4/247)         dfstp     Temp@6
      00000063(30/3/8)           align16   
      00000070(31/3/8)        Label     __N3
      00000070(32/6/136)         dfld      Temp@6
   0013            if (RMAX >= ABS(a(1,j))) cycle                                                AT 73
      00000073(36/7/56)          mov       ecx,Temp@3
      00000076(33/6/136)         dfadd     RSUM
      00000079(34/5/19)          dfstp     RSUM
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Apr 17, 2015 5:08 pm    Post subject: Reply with quote

John answered it: the post-77 syntax fools the optimizer, which was probably implemented for FTN77 - and I guess that when Paul works his way round to it he'll find that knowledge useful.

Ha! Primum non nocere. I'll remember that one. Optimizers have been known for some time to occasionally create flawed executables. I used to test for such things by running my code through lots of compilers, so hence I'm wary about extensions, but Clearwin+ is so seductive I've abandoned that virtue ...

Eddie
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 -> 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