forums.silverfrost.com

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Here is a small code that displays the huge slowdowns caused by underflow interrupts occurring in DAXPY type code in Fortran. These slowdowns occur when underflow exceptions are handled in the default mode of code compiled with FTN95. Most of the issues were written up in another long thread, see http://forums.silverfrost.com/viewtopic.php?t=2465&postdays=0&postorder=asc&start=0, but here is a compact test code.

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Here is an even simpler example, for those who may be a bit worried about downloading a binary file from an "unknown" person. This example does not need a data file, and does not do a DAXMY operation.

DanRRight · Posted: Wed Feb 18, 2015 5:19 pm Post subject:

Interesting. Why

call mask_underflow@()

does not do the same thing?

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Exception handling is an arcane and complicated art. Interrupts/traps do not follow the orderly flow of logic in a program. If an exception is unmasked by calling a service routine within the program, the exception flags have to be restored before calling a library routine and when that routine returns. There may be OS conventions about saving exception control registers, setting your desired values and restoring the old values at subprogram return or other places. Conventions are also needed as to who (the user program or library routine that caused the trap, the OS, the default signal handler or the user-supplied replacement handler) is responsible for doing the saves and restores.

Finally, when your exception handler decides to increment a count of , say, underflow, it has to supply a reasonable value (such as zero) for the result of the expression whose evaluation caused the exception, return to the point in the user program or library routine where the exception was taken, and restore the program state; moreover, this cannot be done directly but through the OS and the compiler's runtime, and requires facilities and cooperation from the OS.

A scholarly article about this topic: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_handle.html .

DanRRight · Posted: Wed Feb 18, 2015 11:49 pm Post subject:

One more interesting thing: when i changed env.variables as above the small code above was compiled OK but compilation of my own ones started producing this error

*** Internal compiler error - floating point exception

Only removing env.variable and rebooting computer helped...

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Interesting.

The compiler itself depends on Salflibc.DLL. If you have a constant expression of type REAL in your program, the compiler may invoke FPU routines in the DLL to evaluate them once for all, and put the resulting value into the OBJ and EXE. If the code in the DLL checks the environment variable, and the evaluation of the expression causes an FPU exception, and the compiler expects exceptions to be masked and handled in the default way, it may get stuck.

I am speculating, of course, since I have no real information about the innards of the DLL.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Mecej4,

Thanks very much for the simplified example of the problem.

I enhanced the first example above to:
include the use of MASK_UNDERFLOW@, and
"estimate" the delay due to floating point exception handling

the revised program is:

DanRRight · Posted: Thu Feb 19, 2015 8:15 am Post subject:

John
Are you getting the compiler crash too or not? I misunderstood.

I was changing env variable in ControlPanel/System/Settings and seems changing it back by removing the line did not work until computer reboot.

By the way if you remember it was these damn underflows which caused the crash of the running code if you do multitasking jalih' s or Paul's way. Masking them by calling Silverfrost's @ utility helped to avoid crashes, that was good suggestion by Paul.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Dan,

I am setting the environment variable in the batch file or at the cmd.exe prompt.

I did not get the compiler error response using Ver. 7.10.0, that you have reported.
When I run my profile_v6.exe program, for both gauss reduction and skyline solution, the program:
runs the gauss reduction
reports the results
runs the skyline reduction
produces the error during the report when attempting to write real*8 values.

At first it failed with "write (*,*) 'mflop =', mflop" so I replaced ",*)" with a format statement number and went further, but further into the reporting the use of format statement numbers also failed. It looks like there is a stack corruption when there are lots of FPE's. (looks can be deceiving!)

I am going to try the "call MASK_UNDERFLOW@" in the program and see if that changes the behaviour.
To test if it is related to the number of FP exceptions, I shall try a range of /d:n options which modifies the number of FPE's being generated.

It looks like my profile_v6.exe program is being slowed down by FPE's. I now need to test the FPE count in other programs that have slow DAXMY performance.

John

mecej4 · Joined: 31 Oct 2006 Posts: 1886

DanRRight wrote: "Only removing env.variable and rebooting computer helped...". If you are working from a command line, you can easily change the local environment with a one line statement. Changing the environment in the Windows System:Advanced:Environment panel makes the changes apply to all applications from then on, and is probably not a good idea. Furthermore, if you are working in a command window and change the environment in the control panel, the changes do not take effect in the command window.

When you think that you want to run programs with frequent changes to environment variables, as we did in this thread, it is safest to do so within a batch file which changes the environment as desired and then runs your program(s) in the changed environment. When your program is run from the batch file and quits, the batch file also quits and the old environment is "restored". Following this procedure also keeps you safe from the changed environment causing disruptions to subsequent compilations, as you experienced. You can have even finer control over changes to the environment within a batch file using the builtin SetLocal...EndLocal commands.

DanRRight · Posted: Thu Feb 19, 2015 4:52 pm Post subject:

I cornered the problem of internal compiler crash in relatively short piece of code which probably Paul has to look at closely. because if we will start using masking routinely we will get eventually this problem. But first please confirm that you see the effect. The fortran file has two subroutines written 30 years ago which worked OK all the time. Together they produce compiler crash if underflows masked. If compiled separately they end up OK.

The ZIP file contains fortran code and batch file which compiles with and without masking underflows (thanks John and mecej4 for the hint)

When you run the batch it produces two files zzzMask and zzzNotMask where compilation process is logged. At the end of them you will see either compilation was OK or failed. Here is the link on Microsoft Onedrive website

mecej4 · Joined: 31 Oct 2006 Posts: 1886

I can reproduce the compile time error. The error message came from the compiler rather than SALFLIBC.DLL.

I observe that in your program there is quite a bit of mixing of REAL*4 and REAL*8 variables and constants in expressions. For example, line 370 has

DanRRight · Posted: Thu Feb 19, 2015 7:15 pm Post subject:

Thanks Mecej4, i think it was good explanation. Changing this variable to real*8 solved the problem.

The only what FTN95 missing in this case is to diagnose such things with exact position and clear message, not just crash usually in the remote place from the offending subroutine. That type of errors will be hard to anticipate by the programmer.

But have you noticed that if there is no second subroutine in the fortran file which is clean the error does not appear? How this can be explained?

mecej4 · Joined: 31 Oct 2006 Posts: 1886

I am glad that you were able to fix the problem based on my suspicions.

I agree that the compiler should issue a more helpful message, but often programs (including compilers) are not given the capability to respond to exceptions, and therefore they give give cryptic messages, or fail with not even a cryptic message, when they unexpectedly find themselves facing an exception.

The response of a compiler to a program with errors is often unpredictable.

DanRRight · Posted: Thu Feb 19, 2015 8:34 pm Post subject:

My wish always was that all recent generations of compilers must have to be way more verbose and suggestive. User-fiendly is another word. Specifically Fortran has to be very simple and user-friendly if we want it to be actively accepted by the new programmers

Returning to this error, hopefully that was right guess and not some other devilry Smile

. The question i asked in previous messages was this: the R.FOR file has two subroutines. The second is fine and has no problems. All the problems are in the first one. But the compiler crash only happens if both are in the same file like it is now.
So if i separate two these subroutines there is no compiler crash. Do you see that too and can you explain this devilry?