Bug report: adding -fast to thecompilation

Question

Hi all.
Compiling the following piece of code on a Sun v60x, I ran across a bug with -fast:
PROGRAM SMOOTH
IMPLICIT NONE
INTEGER, PARAMETER :: i0=100, j0=100, m0=19
INTEGER :: i, j
REAL, DIMENSION(i0,j0) :: rho
INTEGER, DIMENSION(i0,j0) :: imask
LOGICAL, DIMENSION(i0,j0) :: lmask
c sumi1, sumi2, sumi3, sumi4, sumi5 use an integer mask to compute sums
c suml1, suml2, suml2 use a logical mast to compute sums.
REAL, DIMENSION(i0) :: sumi1, sumi2, sumi3, suml1, suml2, suml3,
$ sumi4, sumi5
c set up a checkboard pattern of 1 and 0, or T and F.
imask(1:i0:2,1:j0:2)=1
imask(2:i0:2,1:j0:2)=0
imask(1:i0:2,2:j0:2)=0
imask(2:i0:2,2:j0:2)=1
lmask(1:i0:2,1:j0:2)=.true.
lmask(2:i0:2,1:j0:2)=.false.
lmask(1:i0:2,2:j0:2)=.false.
lmask(2:i0:2,2:j0:2)=.true.
rho = 10.0
print *,'m0=', m0
suml1(: )= SUM(rho(1:m0+1,: ),DIM=1, MASK=lmask(1:m0+1,: ))
sumi1(: )= SUM(rho(1:m0+1,: ),DIM=1, MASK=imask(1:m0+1,: ).eq.1)
sumi5(: )=SUM(rho(1:m0+1,: )*imask(1:m0+1,: ), DIM=1)
DO j=1,j0
sumi2(j)= SUM(rho(1:m0+1,j), MASK=imask(1:m0+1,j).EQ.1)
ENDDO
do j=1,j0
suml2(j)= SUM(rho(1:m0+1,j), MASK=lmask(1:m0+1,j))
enddo
do j=1,j0
sumi4(j)= SUM(rho(1:m0+1,j)*imask(1:m0+1,j))
enddo
suml3=0.0
do j = 1, j0
DO i=1,m0+1
if (lmask(i,j)) THEN
suml3(j)=suml3(j)+rho(i,j)
ENDIF
ENDDO
ENDDO
sumi3=0.0
DO j=1,j0
do i = 1, m0+1
sumi3(j)=sumi3(j)+rho(i,j)*imask(i,j)
ENDDO
ENDDO
DO j = 1, j0
print *,'j=', j,sumi1(j), sumi2(j), sumi3(j), sumi4(j),sumi5(j)
$ , suml1(j),suml2(j)
$ , suml3(j)
enddo
print *,lmask(:,j0)
print *,imask(:,j0)
END PROGRAM SMOOTH
The above program calculates the sum of part of array, not including elements of the array excluded by either an integer mask (imask), or a logical mask (lmask). Each sum calculation (e.g. sumi1) should give identical results - each element of a particular line in the print statement of the final DO loop should report the same result. The purpose of this code is to test various techniques against one another for speed comparisons in a code analyzer. Without the -fast compiler switch the results are as expected:
f90 -V -g subavsun.F -o subavf90: Sun Fortran 95 8.0 2004/07/15
fpp: Sun Fortran Utils 5.4 2004/07/15
f90comp: Sun Fortran 95 8.0 2004/07/15
f90comp: 88 SOURCE LINES
f90comp: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.382
uname -aSunOS 5.9 Generic_117172-07 i86pc i386 i86pc
partial sample of results:
m0= 19
j= 1 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
j= 2 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
j= 3 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
j= 4 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
now add the -fast option:
f90 -V -fast -g subavsun.F -o subavf90: Sun Fortran 95 8.0 2004/07/15
fpp: Sun Fortran Utils 5.4 2004/07/15
f90comp: Sun Fortran 95 8.0 2004/07/15
f90comp: 88 SOURCE LINES
f90comp: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
ir2hf: Sun Compiler Common 9.0 2004/07/15
ube_ipa: Sun Compiler Common 9.0 2004/07/15
ube: Sun Compiler Common 9.0 2004/07/15
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.382
and I get:
m0= 19
j= 1 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
j= 2 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
j= 3 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
j= 4 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
j= 5 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
Interestingly enough, recompile with m0 < 19 the results are fine (with or without -fast):
m0= 18
j= 1 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
j= 2 90.0 90.0 90.0 90.0 90.0 90.0 90.0 90.0
j= 3 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
j= 4 90.0 90.0 90.0 90.0 90.0 90.0 90.0 90.0
j= 5 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0
The problem seems to be with the calculations of sum3i, sum4i, sum5i, all of which involve multiplying a real number (stored in rho) by the appropriate element of the integer mask (imask). Note that this result is peculiar to our Sun v60x; one of our other Suns:
uname -a SunOS 5.8 Generic_108528-22 sun4u sparc SUNW,Sun-Fire
f90 -V -fast subavsun.F -o subavf90: Warning: -xarch=native has been explicitly specified, or implicitly specified by a macro option, -xarch=native on this architecture implies -xarch=v8plusb which generates code that does not run on pre UltraSPARC III processors
f90: Sun WorkShop 6 update 2 Fortran 95 6.2 2001/05/15
fpp: Sun WorkShop 6 update 2 Fortran Utils 5.3 2001/05/15
f90comp: Sun WorkShop 6 update 2 Fortran 95 6.2 2001/05/15
f90: Cray CF90 Version 3.x.x.x (f41pXXgXXXa48) Tue Apr 19, 2005 11:32:53
f90: COMPILE TIME 0.250000 SECONDS
f90: MAXIMUM FIELD LENGTH 5018158 DECIMAL WORDS
f90: 88 SOURCE LINES
f90: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
iropt: Sun WorkShop 6 update 2 Compiler Common 6.2 Patch 111678-06 2001/12/10
cg: Sun WorkShop 6 update 2 Compiler Common 6.2 Patch 111678-06 2001/12/10
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.290
gives good results. I'm not sure which element of -fast is causing the problem - with a bit of work I could probably narrow it down, but I thought people should be aware of the bug. Clearly the compiler is doing something strange.
Thanks.
Cheers,
Mike
Mike Casey
Research Assistant
Department of Oceanography
Dalhousie University
Halifax, Nova Scotia, Canada
email: [email protected]
work: phone: [phone]
FAX: [phone]
_____________________________________________________________

Answer 1

I was able to reproduce your problem with the current studio 9 patch:
f90: Sun Fortran 95 8.0 Patch 115985-02 2004/10/12
f90comp: Sun Fortran 95 8.0 Patch 115985-02 2004/10/12
f90comp: 86 SOURCE LINES
f90comp: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
ir2hf: Sun Compiler Common 9.0 Patch 115982-04 2005/03/22
ube_ipa: Sun Compiler Common 9.0 Patch 115982-04 2005/03/22
ube: Sun Compiler Common 9.0 Patch 115982-04 2005/03/22
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.380
$ a.out
m0= 19
j= 1 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
j= 2 100.0 100.0 0.0E+0 1.4012985E-43 0.0E+0 100.0 100.0 100.0
However, the test appears to run correctly with the studio 10 compiler.
Peter Miller