|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 16, 2015 4:47 am Post subject: Optimizer bug in FTN95 7.10 |
|
|
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
instead of the correct output, which is
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Apr 16, 2015 7:46 am Post subject: |
|
|
Thanks. I have logged this for investigation. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Apr 16, 2015 10:22 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 16, 2015 11:25 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Apr 17, 2015 12:51 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Apr 17, 2015 1:14 pm Post subject: |
|
|
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 |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Fri Apr 17, 2015 5:08 pm Post subject: |
|
|
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 |
|
|
|
|
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
|