On 10/24/2021 2:13 PM, Daniel Feenberg wrote:
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:Something is broken in your installation/version of gfortran. Compiling
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
and run it under gdb with a breakpoint at the first executable statement:: >>
Breakpoint 1, test () at test.for:2
2 write(*,*) 'a'
(gdb) n
a
3 write(*,*) 50.
( gdb) n
Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7ba5a21 in ?? () from /lib64/libgfortran.so.3
It appears that the attempt to write a small integer triggers an arithmetic exception. Which seems very unlikely.
.Wouldn't that be worthy of mention in the docs.?
Daniel Feenberg
your program with version 11.2 I get the following output:
a
50.0000000
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
and run it under gdb with a breakpoint at the first executable statement::
Breakpoint 1, test () at test.for:2
2 write(*,*) 'a'
(gdb) n
a
3 write(*,*) 50.
( gdb) n
Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7ba5a21 in ?? () from /lib64/libgfortran.so.3
It appears that the attempt to write a small integer triggers an arithmetic exception. Which seems very unlikely.
.Wouldn't that be worthy of mention in the docs.?
Daniel Feenberg
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
Daniel Feenberg
On 10/24/2021 4:13 PM, Daniel Feenberg wrote:
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
<--- CUT --->
Daniel Feenberg
I see the bug with gcc version 10.2.0 (GCC) under Cygwin-64 bit onHmmm. My system is ubuntu with gfortran 9.3 and it shows the bug. But man gfortran does not include precision in the list of possible ffpe-trap=list options. Is that option legal? If so, what is it supposed to do? If not, should it give a compile-time
Windows 10-64 bit.
-- CyrMag
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
It appears that the attempt to write a small integer triggers an arithmetic exception. Which seems very unlikely.
.Wouldn't that be worthy of mention in the docs.?
Daniel Feenberg
So, correctly it seems to state that 50.000 cannot be represented
exactly.
On 10/25/2021 7:36 AM, JRR wrote:
So, correctly it seems to state that 50.000 cannot be represented
exactly.
That is not true; the exact representation of 50.0 as a 32-bit real is Z'42480000'. Note that there are 19 zero bits at the least significant
end, so there is plenty of leeway for representing more complicated
numbers than 50.0 using a 23 bit significand.
There is something going wrong, causing a trap to be signaled.
On 10/25/2021 7:36 AM, JRR wrote:
So, correctly it seems to state that 50.000 cannot be represented
exactly.
That is not true; the exact representation of 50.0 as a 32-bit real is Z'42480000'. Note that there are 19 zero bits at the least significant
end, so there is plenty of leeway for representing more complicated
numbers than 50.0 using a 23 bit significand.
There is something going wrong, causing a trap to be signaled.
-- CyrMag
Cyrmag wrote:
On 10/25/2021 7:36 AM, JRR wrote:
So, correctly it seems to state that 50.000 cannot be represented
exactly.
That is not true; the exact representation of 50.0 as a 32-bit real is Z'42480000'. Note that there are 19 zero bits at the least significant
end, so there is plenty of leeway for representing more complicated
numbers than 50.0 using a 23 bit significand.
There is something going wrong, causing a trap to be signaled.
-- CyrMagIf you compile your code, including the one in this thread, with -ffpe-trap=inexact, it will likely die. For any (non-trivial) code,
which is doing floating point arithmetic, the code will raise FE_INEXACT.
For the particular problem with "write(*,*) 50.", the runtime library is doing floating arithmetic to determine if it should write "50.00000" or "0.5E+02" or a few other checks.
If you (generic you here) want to find the location, then compile your
code with "-g" and use gdb.
% cat > a.f90
write(*,*) 50.
end
% gfcx -o z -g a.f90
% ./z
50.0000000
% gfcx -o z -g -ffpe-trap=inexact a.f90
% ./z
Floating exception (core dumped)
% gdb ./z z.core
#0 0x0000000200a73dd9 in get_float_string (dtp=0x7fffffffe4b0,
f=<optimized out>, source=<optimized out>, kind=4, comp_d=1, buffer=0x7fffffffde20 "", precision=<optimized out>, size=<optimized out>, result=<optimized out>, res_len=<optimized out>)
at ../../../gccx/libgfortran/io/write_float.def:1110
1110 FORMAT_FLOAT(4,)
(gdb) list
1105 }
1106
1107 switch (kind)
1108 {
1109 case 4:
1110 FORMAT_FLOAT(4,)
1111 break;
1112
1113 case 8:
1114 FORMAT_FLOAT(8,)
So, you need to go read FORMAT_FLOAT in write_float.def.
--
steve
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:.
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
and run it under gdb with a breakpoint at the first executable statement::
Breakpoint 1, test () at test.for:2
2 write(*,*) 'a'
(gdb) n
a
3 write(*,*) 50.
( gdb) n
Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7ba5a21 in ?? () from /lib64/libgfortran.so.3
It appears that the attempt to write a small integer triggers an arithmetic exception.
Which seems very unlikely.
.Wouldn't that be worthy of mention in the docs.?
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program test
write(*,*) 'a'
write(*,*) 50.
stop
end
On Sunday, October 24, 2021 at 2:13:05 PM UTC-7, feen...@gmail.com wrote:But there may be situations where the user wants to know precision has been lost even in I/O library routines. (I don't know of any but that may just be my ignorance.)
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program testSome (many!) years ago, I was at a Kahan seminar on floating point arithmetic, where he mentioned that no processors have an exception
write(*,*) 'a'
write(*,*) 50.
stop
end
for precision loss. After, I asked about IBM S/360 and successors,
which do have one. But only for all precision loss. If even one bit
is left, no interrupt.
Even more, the usual way to zero a register is to subtract it from
itself, so would cause the interrupt.
But otherwise, I/O library routines should save the flag state,
and set appropriate flags for their use. Then restore before
returning.
But otherwise, I/O library routines should save the flag state,
and set appropriate flags for their use. Then restore before
returning.
But there may be situations where the user wants to know
precision has been lost even in I/O library routines.
(I don't know of any but that may just be my ignorance.)
On Sunday, October 24, 2021 at 2:13:05 PM UTC-7, feen...@gmail.com wrote:.
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program testSome (many!) years ago, I was at a Kahan seminar on floating point arithmetic, where he mentioned that no processors have an exception
write(*,*) 'a'
write(*,*) 50.
stop
end
for precision loss. After, I asked about IBM S/360 and successors,
which do have one. But only for all precision loss. If even one bit
is left, no interrupt.
Even more, the usual way to zero a register is to subtract it from
itself, so would cause the interrupt.
On Sunday, October 24, 2021 at 2:13:05 PM UTC-7, feen...@gmail.com wrote:.
Is there somewhere a discussion of gfortran option "ffpe-trap=precision"? I tried recompiling my code with all the debugging traps enabled, but I couldn't make "Arithmetic Exception" go away. Eventually I made this test program:
program testSome (many!) years ago, I was at a Kahan seminar on floating point arithmetic, where he mentioned that no processors have an exception
write(*,*) 'a'
write(*,*) 50.
stop
end
for precision loss. After, I asked about IBM S/360 and successors,
which do have one.
But only for all precision loss. If even one bit.
is left, no interrupt.
Even more, the usual way to zero a register is to subtract it from
itself, so would cause the interrupt.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 99:59:35 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,979 |