assume:noprotect_constants debugger exception

[polarbear00]

Hi,

I am evaluating the Intel compiler and I am running into an issue using the /assume:noprotect_constants switch. I am using the switch to overcome some issues in the code where the program modifies a constant actual argument. When I run the Release version of the program the program gets past these issues and I run into other issues. It would be helpful to use the debugger to solve these other problems so I try to run the Debug version with the switch set to Yes(/assume:noprotect_constants), but I am still getting the constant exception. Does anyone know what other switch/switches I need to set to ignore this exception when running in debug mode?

Thanks,

Bob

[Steven_L_Intel1]

Are you sure that's the cause of the error? Did you compile the routine that passes the constant with this option?

[polarbear00]

Hi Steve,

Yes I am sure that this is the cause of the error, but I've been sure\wrong before ;-)

The call looks like this: CALL ANGLE (GGMR,SGMR,T1,T2,1)

Inside Angle we have some code like this:

subroutine angle(tang,txsin,txcos,txtan,ik)
k = ik ! Set the internal var to ik
! A little bit later we set ik to k, don't ask why.
ik = k! oops"Unhandled exception at....."

Using the IDE, I selected the first node of the project and modified it's properties to use "assume:noprotect_contants". If I look at the individual properties of the source files involved they have the switch set correctly.

In release mode this switch works as expected, in debug mode it is not. I'm wondering if some other switch is negating the assume:noprotect_constants switch? Below is the compile switches for Angle.

ifort /nologo /debug:full /Od /warn:interfaces /assume:noprotect_constants /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c /extfor:f95 /free /Qvc10 /Qlocation,link,"C:\Program Files\Microsoft Visual Studio 10.0\VC\\bin" "C:\LF9557\Fortran95\Source\ANGLE.f95"

Thanks,
Bob

[Steven_L_Intel1]

Are you compiling the caller the same way? That's where the switch matters, because it changes how constants are passed in the call.

[polarbear00]

Yes, beloware the compiler options for the calling routine.

ifort /nologo /debug:full /Od /warn:interfaces /real_size:64 /assume:noprotect_constants /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c /extfor:f95 /free /Qvc10 /Qlocation,link,"C:\Program Files\Microsoft Visual Studio 10.0\VC\\bin" "C:\LF9557\Fortran95\Source\R60813.f95"

[Steven_L_Intel1]

Can you construct a small test case I can look at?

[polarbear00]

Hi Steve,

Please let me know if you can't access the short example I attached. If you build and run the example you will get the exception I am referring to on line 14 of the angle.f90 source file. Please let me know if I can give you any other information.

Thanks,

Bob

[Steven_L_Intel1]

Thanks - this helps a lot.

There appears to be an unwanted interaction between /assume:noprotect_constants and /warn:interface. If a generated interface is seen, the compiler ignores /assume:noprotect_constants! I'll report this to the developers.

A workaround is to disable /warn:interface for the project ("Check Routine Interfaces" under Diagnostics.)

[polarbear00]

Hi Steve,

Thanks,your solution works like a charm. I am not familiar with the term "generated interface," what part of my source code was a generated interface and do you know whereI can find more information about this on the web? Thanks again for the solution and your quick responses.

Best regards,
Bob

[Steven_L_Intel1]

Generated interface checking is a diagnostic feature of the compiler. What it does is look at subroutines and functions as they are compiled and, for each one that is an "external" procedure (that is, not contained in a module or other procedure), it generates a module with a Fortran interface block for the routine. These are the __GENMOD.f90 and .mod files you see in the Debug folder. Then, when the compiler sees a call to a routine for which it does not have an explicit interface (such as from a module), it looks to see if there is a generated interface for it and compares the arguments looking for mismatches. If it finds a mismatch, it will report an error. This is a great diagnostic tool but we've had issues in the past where seeing a generated interface causes the compiled code to change, which it should never do. This is another one.

Your source code is fine, though of course I always recommend using modules for your procedures so that the caller always knows what the called routine looks like. If you put subroutine ANGLE in a module and then USE the module from the caller, you would not run into this bug and would have safer code (not dependent on a compiler feature to find argument mismatches.)

I have escalated this as issue DPD200166227.

[polarbear00]

Steve,

Thank you for the explanation and again thanks for the help.

Until next time,
Bob

[Steven_L_Intel1]

I expect this problem to be resolved in 12.0 Update 4.