Home > Archive > Fortran > April 2007 > division by zero error
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
division by zero error
|
|
| Kamaraju S Kusumanchi 2007-04-19, 7:05 pm |
| Can someone please explain where I am dividing by zero in this code? Is this
a bug in absoft compiler? I am using Debian Etch (stable).
Consider
$cat exception.f90
program exception
implicit none
real :: pre
real :: a
a=3.0
pre = 1.0/((a-1) * a)
write(*,*) pre
end program exception
$/opt/absoft/bin/f90 -trap=ALL -et -V exception.f90
f90: Copyright Absoft Corporation 1994-2002; Absoft Pro FORTRAN Version 8.0
f90fe: 9 source lines
f90fe: 0 Errors, 0 Warnings, 0 Other messages, 0 ANSI
$./a.out
An exception occurred on: Thu Apr 19 19:20:48 2007
****************************************
**********
****************************************
**********
Diagnostic information:
The signal number is 8 SIGFPE
Erroneous arithmetic operation, such as division by zero or an operation
resulting in overflow.
The signal code is FPE_FLTRES
Floating point inexact result
Procedure Traceback:
Error occurred in the file: exception.f90, at routine main, at or near line
7
Compiler producer: Absoft
Floating point exception (core dumped)
hth
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Michael Metcalf 2007-04-19, 7:05 pm |
|
"Kamaraju S Kusumanchi" <kamaraju@bluebottle.com> wrote in message
news:f08tkm$pis$1@ruby.cit.cornell.edu...
> Can someone please explain where I am dividing by zero in this code?
You're not.
>Is this
> a bug in absoft compiler?
Possibly. Try (a-1.0)
Regards,
Mike Metcalf
| |
| Kamaraju S Kusumanchi 2007-04-19, 10:03 pm |
| Michael Metcalf wrote:
>
> "Kamaraju S Kusumanchi" <kamaraju@bluebottle.com> wrote in message
> news:f08tkm$pis$1@ruby.cit.cornell.edu...
>
> You're not.
>
Thanks. Most of the times when I thought I hit a compiler bug, it turned out
that it is a mistake in my code. So I was just making sure.
>
> Possibly. Try (a-1.0)
>
OK. I removed the 1.0 in the denominator completely.
$cat exception2.f90
program exception
implicit none
real :: pre
real :: a
a=3.0
pre = 1.0/(a * a)
write(*,*) pre
end program exception
$/opt/absoft/bin/f90 -trap=ALL -et -V exception2.f90
f90: Copyright Absoft Corporation 1994-2002; Absoft Pro FORTRAN Version 8.0
f90fe: 9 source lines
f90fe: 0 Errors, 0 Warnings, 0 Other messages, 0 ANSI
$./a.out
An exception occurred on: Thu Apr 19 20:26:57 2007
****************************************
**********
****************************************
**********
Diagnostic information:
The signal number is 8 SIGFPE
Erroneous arithmetic operation, such as division by zero or an operation
resulting in overflow.
The signal code is FPE_FLTRES
Floating point inexact result
Procedure Traceback:
Error occurred in the file: exception2.f90, at routine main, at or near line
7
Compiler producer: Absoft
Floating point exception (core dumped)
Any further ideas/comments/suggestions?
thanks
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| Steven G. Kargl 2007-04-19, 10:03 pm |
| In article <f091e3$8nr$1@ruby.cit.cornell.edu>,
Kamaraju S Kusumanchi <kamaraju@bluebottle.com> writes:
>
> OK. I removed the 1.0 in the denominator completely.
>
> $cat exception2.f90
> program exception
> implicit none
> real :: pre
> real :: a
>
> a=3.0
> pre = 1.0/(a * a)
> write(*,*) pre
> end program exception
>
> $/opt/absoft/bin/f90 -trap=ALL -et -V exception2.f90
What does -trap=ALL do?
> The signal code is FPE_FLTRES
> Floating point inexact result
I suspect that this is your answer. Does 1.0 / 9.0 give
an exact IEEE-754 result?
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Gordon Sande 2007-04-19, 10:03 pm |
| On 2007-04-19 20:23:19 -0300, Kamaraju S Kusumanchi
<kamaraju@bluebottle.com> said:
> Can someone please explain where I am dividing by zero in this code? Is this
> a bug in absoft compiler? I am using Debian Etch (stable).
>
> Consider
> $cat exception.f90
> program exception
> implicit none
> real :: pre
> real :: a
>
> a=3.0
> pre = 1.0/((a-1) * a)
> write(*,*) pre
> end program exception
>
>
> $/opt/absoft/bin/f90 -trap=ALL -et -V exception.f90
> f90: Copyright Absoft Corporation 1994-2002; Absoft Pro FORTRAN Version 8.0
> f90fe: 9 source lines
> f90fe: 0 Errors, 0 Warnings, 0 Other messages, 0 ANSI
Some time ago there was a problem with a version of Absoft for MacOS/9
where the overflow it reported had happened before the program was started.
They were not clearing enough flags on startup. They fixed the issue after
grumbling about changes made by Apple on one of the point releases. I may
have some details a bit off as it was a long time ago and the issue was fixed.
It was a nuisance while it was present as it was intermitant. Can you say
Hiesenbug?
Perhaps an equivalent problem is present with your version of Linux, the
shell you are using, etc, etc. That is why the vendors claim particular
versions of the host operating system as being supported with only a
wish for good luck with other versions.
> $./a.out
> An exception occurred on: Thu Apr 19 19:20:48 2007
> ****************************************
**********
> ****************************************
**********
> Diagnostic information:
> The signal number is 8 SIGFPE
> Erroneous arithmetic operation, such as division by zero or an operation
> resulting in overflow.
> The signal code is FPE_FLTRES
> Floating point inexact result
>
> Procedure Traceback:
> Error occurred in the file: exception.f90, at routine main, at or near line
> 7
> Compiler producer: Absoft
> Floating point exception (core dumped)
>
>
> hth
> raju
| |
| Kamaraju S Kusumanchi 2007-04-19, 10:03 pm |
| Steven G. Kargl wrote:
>
> What does -trap=ALL do?
>
From the compiler's manual
-trap=exception[,exception,...]
Enable one or more FPU floating point exceptions. Exception can be
one or more of INVALID, DIVBYZERO, OVERFLOW, UNDERFLOW, INEXACT, or ALL.
This option only applies to the MAIN program unit.
>
> I suspect that this is your answer. Does 1.0 / 9.0 give
> an exact IEEE-754 result?
>
I guess you are right that it is an inexact computation and that is why trap
is spewing errors. However, I am puzzled that it is resulting in a coredump
and the commands (write statement in this case) are not executed at all.
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/
| |
| robert.corbett@sun.com 2007-04-19, 10:03 pm |
| On Apr 19, 6:00 pm, k...@troutmask.apl.washington.edu (Steven G.
Kargl) wrote:
> What does -trap=ALL do?
>
>
> I suspect that this is your answer. Does 1.0 / 9.0 give
> an exact IEEE-754 result?
The inexact exception is the exception that is the rule.
Sun Fortran provides equivalent trapping functionality over my
strong objections. Making it easy to trap on the inexact
exception is a bad idea.
Bob Corbett
| |
| robert.corbett@sun.com 2007-04-20, 4:07 am |
| On Apr 19, 6:21 pm, Kamaraju S Kusumanchi <kamar...@bluebottle.com>
wrote:
> Steven G. Kargl wrote:
>
>
> From the compiler's manual
>
> -trap=exception[,exception,...]
> Enable one or more FPU floating point exceptions. Exception can be
> one or more of INVALID, DIVBYZERO, OVERFLOW, UNDERFLOW, INEXACT, or ALL.
> This option only applies to the MAIN program unit.
>
>
>
> I guess you are right that it is an inexact computation and that is why trap
> is spewing errors. However, I am puzzled that it is resulting in a coredump
> and the commands (write statement in this case) are not executed at all.
The option -trap=ALL causes most of the trap mask bits in the FPU
Control Word (FCW) and the MXCSR to be cleared. The likely exception
is the mask bit for the denormal operand exception. Therefore,
whenever
a floating-point operation produces an inexact result, which is much
of the
time, the program is going to trap to the floating-point signal
handler.
On a UNIX-like system, the default signal handler for a floating-point
exception (SIGFPE) is SIG_DFL, which writes a diagnostic message and
terminates execution.
The WRITE statement doesn't write anything because execution is
terminated before the program reaches the WRITE statement.
Bob Corbett
|
|
|
|
|