Test2.f95 has this code: program test2 real :: start, finish, dog call cpu_time(start) dog = 1.0 dog = dog*dog call cpu_time(finish) print '("Time = ", f6.3, " seconds." )', finish - start end program test2 I compiled it with: gfortran -O0 -ffpe-trap='precision' test2.f95 and on running got this error: Floating point exception
*** Bug 30781 has been marked as a duplicate of this bug. ***
This works for me on x86 linux-gnu.
troutmask:sgk[223] gfc4x -o z -g -ffpe-trap='precision' g.f90 troutmask:sgk[224] gdb ./z (gdb) run Starting program: /usr/home/sgk/tmp/z Program received signal SIGFPE, Arithmetic exception. 0x000000000040a3b2 in *_gfortrani_cpu_time_4 (time=0x7fffffffe988) at ../../../gcc4x/libgfortran/intrinsics/cpu_time.c:160 160 *time = sec + usec * (GFC_REAL_4)1.e-6; I have no idea how to fix this problem at the moment. This is on amd64-*-freebsd.
I have no idea how to fix this problem at the moment. It is hard as there are no functions which convert from a floating point to an integer that might not raise a signal. This is why setting trapping on precision is almost something you never want to do.
I modified cpu_time_4 to just return some dummy values, and experimented a bit with the test case. When I commented out the print statement, the exception went away. Here is a reduced test case. program test2 real :: dog dog = 1.0 print *, dog end program test2 The exception is occurring in the print statement. Nothing to do with time. (gdb) r Starting program: /home/jerry/prs/pr30780/a.out Program received signal SIGFPE, Arithmetic exception. 0x00002aaaaab2c3d9 in write_float (dtp=0x7fff52698b00, f=0x7fff52698a50, source=<value optimized out>, len=<value optimized out>) at ../../../gcc43/libgfortran/io/write.c:366 366 if ((m > 0.0 && m < 0.1 - 0.05 / exp_d) || (m >= exp_d - 0.5 ) ||
(In reply to comment #5) > The exception is occurring in the print statement. Nothing to do with time. > No, there is a "problem" in cpu_time. -ffpe-trap='precision' is trapping on lost precision. On x86_64, long is 64-bit and GFC_REAL_4 is 32-bit with only 24-bits of precision. You can't convert long to GFC_REAL_4 without loss of precision. In short, using this option is probably not a good idea if you have mixed mode math.
OK, then there is a similar, not necessarily related problem in write.c.
I'm changing this into a documentation PR, and assign it to myself. It was decided that there really isn't a good way to provide high-quality timer functions with precision-loss trapping. We need to document this shortcoming in the -ffpe-trap option doc.
> We need to document this shortcoming in the -ffpe-trap option doc. Maybe one should put it additionally also in the documentation of the CPU_TIME intrinsic subroutine.
(In reply to comment #9) > Maybe one should put it additionally also in the documentation of the CPU_TIME > intrinsic subroutine. Yep, but I suspect that CPU_TIME is not the only routine library routine that can trigger this exception. I don't feel like going through all library routines and check which can fail, but the I/O system certainly can trigger it also, as Jerry observed, so I was thinking of adding a more general kind of remark.
Subject: Bug 30780 Author: fxcoudert Date: Wed Sep 26 22:27:16 2007 New Revision: 128825 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128825 Log: PR fortran/30780 * invoke.texi: Add note to -ffpe-trap option. Fix typos. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
Documentation added.