This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math
- From: Paul van Delst <Paul dot Vandelst at noaa dot gov>
- To: fortran at gcc dot gnu dot org
- Date: Tue, 05 Jul 2011 12:36:28 -0400
- Subject: Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math
- References: <20110702123621.200953BE0F@mailhost.lps.ens.fr>
Hello Dominique,
Dominique Dhumieres wrote:
> Paul,
>
>> Trying the options one-by-one, it was the -funsafe-math-optimizations
>> option that caused the program to crash using gfortran 4.4.4.
>
> Could you try
> -O3 -funsafe-math-optimizations -ffinite-math-only -fno-reciprocal-math
> and
> -O3 -funsafe-math-optimizations -ffinite-math-only -fno-tree-vectorize
> ?
I will give them a try today (we just had long weekend) and report back.
> What you describe reminds me pr43716
> ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 ).
> This pr appeared and disappeared without convincing explanation
> and could be a rampant bug exposed by your code. Does it contain
> constructs such as the one in comment #13?
The immediate vicinity of the source where the problem manifests itself (a segfault at line1514) is shown below:
1500 !
1501 ! --- Set weights for forward interpolator
1502 !
1503 dy=y2-y1
1504 dz=z3-z2
1505 if (abs(dz) < SMALLDIFF) then
1506 write(6,*) 'SUBLAYER: ERROR: dz is <=0. dz = ',dz
1507 write(6,*) 'z3,z2,z1 = ',z3,z2,z1
1508 write(6,*) 'px2(j),px2(j+1) = ',px2(j),px2(j+1)
1509 return
1510 else
1511 dzd=ONE/dz
1512 endif
1513 zw1=(z3-y1)*dzd*dy
1514 zw2=(z3-y2)*dzd*dy
where "ONE" is a parameter set to the value 1.0.
Scanning the rest of the code, it doesn't appear that there are any array indices that are computed from fp values, but
there also does not appear to be any range checks. I don't think that should be a concern since (a) this code runs in
debug mode with the array bounds checking on and (b) it's a module that is invoked only after the input data has been
verified.
After reading the last few comments of Bug 43716 I'm wondering if the use of the reciprocal of dz is somehow linked to
this issue.
cheers,
paulv
--
Paul van Delst