why doesn't SQRT(-1.0) give an error?

[DavidWhite]

IRESULT = SQRT(-1.0)

From watch window:
iresult -2147483648 INTEGER(4)

Why does this not fail?

result = SQRT (x)

x	(Input) must be of type real or complex. If x is type real, its value must be greater than or equal to zero.

I'm actually trying to cause my program to fail to prove that /traceback gives an appropriate output for users ... what I found was the program kept on running normally!

2nd Question ... is error handling working ... according to documentation:

Fortran Windows applications

Run-time error messages are displayed in a separate message box.

I'm not ever seeing a separate message box.

[Steven_L_Intel1]

Let's look at a more detailed version of your code:

[fortran]x = sqrt(-1.0)
print *, x
i = x
print *, i
end[/fortran]

When I build and run this without options from a command prompt, I get:

NaN
-2147483648

Taking the square root of a negative number gives you an IEEE "Not a Number" or NaN. If you then assign this to an integer, the result is undefined but we give you the maximum negative number.

If you want an exception, then add the option /fpe0 (in Visual Studio, this is Fortran > Floating Point > Floating Point Exception Handling > 0. Then you would get:

forrtl: error (65): floating invalid
Image PC Routine Line Source
t.exe 00D41041 _MAIN__ 1 t.f90
t.exe 00D88453 Unknown Unknown Unknown
t.exe 00D6E97D Unknown Unknown Unknown
kernel32.dll 768B339A Unknown Unknown Unknown
ntdll.dll 77D79ED2 Unknown Unknown Unknown
ntdll.dll 77D79EA5 Unknown Unknown Unknown

So that answers your first question.

For the second, when the documentation says "Windows applications" it means the kind with no console interface, where the entry point is the function WinMain. You will also see a separate window if you build a QuickWin application.

[DavidWhite]

Steve,

I'm not seeing this behaviour in my production apps, which are full windows programs. Command line in use is below, which already includes /fpe:0

/nologo /debug:minimal /Oy- /I"C:\Dev\Winyldmd Dev\trunk\ymd_modules\Release" /I"C:\Dev\Winyldmd Dev\trunk\ymdphys\Release" /I"C:\Dev\VerCheck\Release" /I"C:\Dev\Winyldmd Dev\trunk\PSDMod\Release" /I"C:\Dev\Winyldmd Dev\trunk\ymd_commands\Release" /I"C:\Dev\Winyldmd Dev\trunk\ymdutils\Release" /warn:declarations /warn:unused /fpe:0 /module:"Release\" /object:"Release\" /Fd"Release\vc100.pdb" /traceback /check:bounds /check:uninit /check:format /libs:static /threads /c

Thanks,


David

[DavidWhite]

Steve,

Tried this
1. Create new windows MDI program using template
2. Add two lines to WinMain:

REAL :: X

X = SQRT(-1.0)
3. Added /fpe:0 to compiler options:
/nologo /debug:full /Od /warn:interfaces /fpe:0 /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /winapp /c
4. compile and run program.
5. X has value NaN when program breaks at this line, but program continues normally as if no error occurs.
----
also tried a similar console program, error traceback occurs in the cmd window. Appears problem is limited to Windows programs.

Thanks,


David

[Steven_L_Intel1]

Ah, I see. The problem there is that when there is no Fortran main program, the Forrtan error handler does not get established. try adding the option /fpe-all:0 - you may need to do this under the "Command Line" property page.

[DavidWhite]

Steve,

I can't get any response from the error handler for WinApp - on my development machine, I get the dialog "do you want to start a new instance of the debugger", on anaother Win7 machine, the app silently dies. I was using no optimization /traceback /fpe-all:0

Thanks,

David

[DavidWhite]

Steve,

Is the failure of the Fortran Error handler to start under Windows apps going to be submitted as a bug report?

Thanks,

David

[Steven_L_Intel1]

Let me ask my library friends about this. I thought it should work.

[Bernard_Candy]

I am having a similar problem...

When i run the debug version of my windows application sqrt(-1.0) generates an exception that I handle using try-catch in a c++ wrapper.

When i run the release version of my windows application sqrt(-1.0) happily assigns NaN to the result and continues. I am using fpe:0 in the release version.

I use the routine SETCONTROLFPQQ to set the floating point flags in both debug and build version and they both use the hex value 0272.

Furthermore...

If in my release build I set as follows:

Fortran->Optimization->Optimization->Maximum Speed the sqrt(-1.0) returns NaN with no exception

If I change this to

Fortran->Optimization->Optimization->Disable the sqrt(-1.0) returnsan exception that I can handle with the c++ try-catch wrapper.

It looks like the optimization settings interfere with the error handling.

[Steven_L_Intel1]

Optimization changes the code used. If an instruction is used instead of a library routine, that can change the behavior. However, in a small example I tried, I get the same behavior (floating invalid) whether I compile with or without optimization and with /fpe:0. Can you show a small example that does otherwise? Please also show all the compile options you are using.

I will note that SETCONTROLFPQQ may not affect some SSE instructions.

[Bernard_Candy]

Hi Steve,

Thanks for the quick response.

The attached solution shows the behaviour I described.

sqrt(-1.0) returns Nan with no exception when Fortran->Optimization->Optimization is set to Maximum Speed.

sqrt(-1.0) generates an exception when Fortran->Optimization->Optimization is set to Disable (/Od).

Cheers
Bernard

[Steven_L_Intel1]

Thanks for the test case. There are several problems with it.

First, you have the C code and the Fortran code using different forms of runtime library, which will interfere with exception handling. A clue to this is your putting in "Ignore library msvcrt.lib" in the linker properties. The fix for this is to change one or the other to use the same library type - I chose to change the C project to link to the static library (/MT) which is what Fortran uses.

Second, Your code uses constant values and the optimizer can do "value propagation" at compile-time so it never needs to do the square root at run-time.

Third, your program never uses the result of the operation, so the optimizer can discard the whole thing.

I replaced your MAIN_MSSG_LOOP routine to include this:

[plain]   character(3) :: minus20="-20"
   character(1) :: zero="0"
   call acknowledge("about to take square root of -20")
   read (minus20,*) x
   x = sqrt(x)
   print *, x
   call acknowledge("taken square root of -20")
   read(zero,*) y
   call acknowledge("about to divide by zero")
   x = 20.0/y
   print *, x
   call acknowledge("divided by zero")[/plain]

so that the optimizer can't do constant folding and value propagation and also so that it can't eliminate the operation. When I do this along with the library fix I get:

[plain] in SetFloatingFlags control =  272(hex)
 about to take square root of -20
Exception handler:  Attempted invalid operation[/plain]

which is what you want.

[Bernard_Candy]

Hi Steve,

Thanks for the excellent feedback!

I reallyshould havethought of some of the things you have mentioned, so will think a bit harder before I post my next question.

Cheers
Bernard