Checklist for errors found by optimization?

[Intel_C_Intel]

I've recently converted inherited F77 code to free-form, and it works great with no or local optimizations. When I get to global optimizations, the following if..then conditional is triggered

if (seprpt .gt. MAXCEL) then
ierr = 57 ! getawet: the cell index exceeds MAXCEL
call errex(ierr)
return
elseif(....)

The code specifying ierr = 57 when it normally shouldn't be.

'seprpt' is a passed integer argument, MAXCEL is a fixed parameter specified in a header file. The debugger in 'no optimizations' mode gives a value for seprpt, but says MAXCEL is an undefined variable.

Previous recommendations in the message board say zip it and send it to you, but this is part of a large VB project and I was hoping there is a checklist for optimizations, it may be a no-brainer.

Thanks,
dfh

[Steven_L_Intel1]

If MAXCEL is a PARAMETER constant, the debugger won't know about it. You may want to put in PRINT statements to see what values seprpt takes on - there are many possible causes, too varied for a checklist.

Steve

[Intel_C_Intel]

The 'seprpt' value changed during execution. The value was very high, 1245188. MAXCEL stayed constant.

seprpt is an integer argument passed in a subroutine, both dummy and targets are explicitly declared, and I initialize the argument directly before each subroutine call.

I will note there are about 4 or 5 dozen files with implicit double precision (a-h,o-z), I'm in the process of taking them out (it could take a day or two), but all integer values are explicitly declared.

BTW, I'm not receiving the e-mail replies.

Thanks,
dfh

[Intel_C_Intel]

To close off the thread,

Well, I got the implicit statements out of the program, and it didn't solve the problem.

But it helped, and it kept my focus on variable declarations. Turns out most of the integer variables were specified as default integer kind, whereas one particular daughter subroutine had the target integer variable specified as Kind=2.

I don't know if the compiler should check for the type compatibility, but I'm glad I got the optimizations working...they knock off more than 50% of the run-time in my application.

dfh

[Steven_L_Intel1]

The compiler can check if /warn=argument_checking is in effect (it is the default in a Debug configuration) and the caller and callee are compiled together. INTERFACE blocks can be a big help for preventing problems of this nature.

Steve

[Intel_C_Intel]

Steve,
I'm pretty sure I had it checked, below are the Project options

/alignment:dcommons /check:bounds /compile_only /debug:full /dll /nologo /optimize:2 /traceback /warn:argument_checking /warn:nofileopt

Is there something else to check? If you need me to give further info, let me know--dfh

[Steven_L_Intel1]

Are the caller and callee in the same source file?

Steve

[Intel_C_Intel]

No, they are in separate source files. Does this mean they compile in separate object files, and the warning wouldn't be triggered because they are compiled separately?

[Steven_L_Intel1]

Yes - exactly.

We are working on a technology to allow cross-file argument checking - it's not quite ready yet...

Steve