Optimization problem in version 37

[dajum]

We have an application that works fine in IVF9.1 for windows version 23 and 24. When we went to version 37 we got the following error. FORRTL: Severe 47: Write to readonly file unit 108 file ... THe file it reports was not the correct name for that unit, it was associated with a different unit. We turned off optimization level 5 and it now works again. Is this a known type of error? I can not send in our application as a sample, so I'm hoping for some help without that.

Dave

[Steven_L_Intel1]

That's a new one to me. I suggest you report it to Intel Premier Support and include what details you can.

I am somewhat puzzled, though - the Intel compiler does not have an optimization level above 3. What exactly did you change?

[jimdempseyatthecove]

Although as Steve points out there is no optimization level 5. That being said, the program behavior indicates something is wrong.

See what happens if you use the same optons that produce the error but also add the runtime check for accessing an array out of bounds. This might point to a problem in your code that you are not aware of.

A typical cause of an optimized program failing where the Debug build succeeds is usually due to uninitialized variables. One of those may cause, perhaps, the index you use on your table of I/O Unit numbers to be used incorrectly. And this results to you assigning the same unit number to multiple files.

This is a simple enough test to perform.

Jim Dempsey

[dajum]

It was compiled with a batch file that used /optimize:5 which appears is a holdover from another compiler, although I found documentation somewhere that said this just set it to /O3. We changed it to /Od and got different results. Part of our problem is that a 3rd party dll is involved and we suspect the problem is inside of that dll, but it is tough for us to pin down exactly where the problem is located.

Thanks for the help.

Dave

[jimdempseyatthecove]

Being a 3rd party DLL makes it difficult to add diagnostics (uninitialized variable test and array subscript out of bounds test).

There are a few things you can do to diagnose potential DLL problems.

1) Make a shell function that calls the DLL using ATTRIBUTES ALIAS might help. In the shell if possible copy the calling arguments to a buffer with severalNULL pads surrounding the copied contents. After each call test the NULLs to verify they remain NULL. If not NULL then it may be a buffer overrun problem or you made a calling arg error (passing in a variable when you were suppose to pass in an array of such variables)

2) Modify the shell function such that it calls a second shell with optional last argument and make the call without the argument thus creating a dummy with "not present" characteristics. Then call the DLL function with an extra argument being that of the non present arg of the second shell. The idea here is to trap into the debugger if the DLL reference the variable represented by the not present argument. This then will indicate your call is in error (missing an argument)

Jim Dempsey