Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29253 ディスカッション

catching divide by zero

tsimm3
新規コントリビューター I
3,455件の閲覧回数

I have not been able to catch divide by zero errors in my code. I've tried many variations of settings in the project file, in debug mode. The result of a divide by zero is infinity, but I want execution to stop and report an error. I reproduced the situation with this code:

program test_divide_by_0
i = 0
z = 1.0/i
print*, z
end

This runs without reporting any error and writes out Infinity. I'm using Composer XE 2013.

0 件の賞賛
10 返答(返信)
lklawrie
ビギナー
3,455件の閲覧回数

Try using /traceback and /fpe:0 -- the /fpe:0 will stop the program at the point of the exception.  /traceback should tell you where it is.

Debug doesn't have to be full on.

tsimm3
新規コントリビューター I
3,455件の閲覧回数

Thanks, Linda. That works with my sample code. Unfortunately still doesn't work with my actual development code. The main difference I can think of is that the development project creates a DLL, not a console application.

tsimm3
新規コントリビューター I
3,455件の閲覧回数

I've discovered that if I insert this statement into my development code I get an error and a traceback, as desired.

real_value = 1/0

However, if I insert this statement I get infinity as the result with no error.

real_value = 1./0.

Steven_L_Intel1
従業員
3,455件の閲覧回数

Add under Command Line > Additional Options:

/fpe-all:0

This enables th /fpe0 behavior for all your routines, not just from the main program.

tsimm3
新規コントリビューター I
3,455件の閲覧回数

Thank you. It works perfectly now. It seems like the /fpe0 option should apply to all routines by default, but I suppose there's a good reason for it being the way it is.

Steven_L_Intel1
従業員
3,455件の閲覧回数

Yes there is - performance.  The code to enable trapping of floating point errors is slow and needs to be run only once, so the default is to do it in the main program. We added /fpe-all for situatioms such as yours where you don't control the main program.

As an alternative, the Fortran standard IEEE_EXCEPTIONS and IEEE_ARITHMETIC intrinsic modules allow you fine-grained control over these features. If you use these, you must compile with /fp:strict to let the compiler know you're modifying the FP environment.

SergeyKostrov
高評価コントリビューター II
3,455件の閲覧回数
That problem was discussed some time ago on Intel C++ compiler forum. If one vector A needs to be divided by vector B then a prescan for vector B could be done in order to verify that it has No any Zero elements ( some corrective logic could be also implemented ). In that case application won't do any divisions by zeros and performance won't be affected.
Steven_L_Intel1
従業員
3,455件の閲覧回数

Sergey, if you were replying to my last comment, you're talking about something very different. I was referring to the instructions needed to change the processor floating point trap behavior - these are slow.

Casey
ビギナー
3,455件の閲覧回数

This isn't so relevent to the thread, but to Sergey's comment.

Sergey Kostrov wrote:

That problem was discussed some time ago on Intel C++ compiler forum. If one vector A needs to be divided by vector B then a prescan for vector B could be done in order to verify that it has No any Zero elements ( some corrective logic could be also implemented ). In that case application won't do any divisions by zeros and performance won't be affected.

Fortan has some builtin mechanisms to accomplish this without the logic you would need in C++.  For example:

[fortran]where (b /= 0.)

  c = a / b

elsewhere

c = 0.

end where

[/fortran]

Assuming a,b,c are real arrays with the same shape.  But, as Steve pointed out, this is a seperate issue from trapping floating point exceptions.

tsimm3
新規コントリビューター I
3,455件の閲覧回数

My original question had absolutely nothing to do with preventing divide by zero errors. That process is well known. Unfortunately, they still happen. My problem was that I couldn't get the compiler to detect them for me, which is something I have relied on for years with many different compilers as I maintained a large program written by a multitude of various programmers with different levels of programming skills. With Steve's suggestion the compiler now works the way I remember previous versions working.

Thanks to everyone who commented.

返信