Problem using MODULE variables as arguments to a subroutine

Problem using MODULE variables as arguments to a subroutine

I have just discovered a problem with a new code where (a tabbed dialog), if I call subroutine and use MODULE variables (one or more) in the argument list, when I examine the values of the dummy arguments corresponding to the module variables inside the routine in debug mode they bear no relation to the actual values of the module variables in the calling program (they gain a large negative or positive exponent for example).

If I create a local copy of a module variable in the calling program and use that as an argument instead, the dummy argument value in the subroutine agrees with the expected value.

The problem occurs for module variables whether defined as a PARAMETER or not. I am using the MODULE to store parameters and values generated elsewhere that I want to make available to program procedures.

I am using VS 2005 and Intel Composer XE 2011.10.235.

Any ideas why this might happen?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

So the problem is viewing the argument in the debugger? Can you come up with an example? I suspect the issue is not related to being a module variable but rather something about the dummy argument declaration.

Retired 12/31/2016

Here is more information. It is not just a case of 'hover over' in the debug window showing rubbish values, rubbish values actually 'turn up in' and are actually used by the called routine.

In my module (call it MODNAME), all real variables are defined as REAL(DOUBLE) and all integer variables are defined as INTEGER(LONG). USE DFWINTY is invoked to define DOUBLE and LONG.(ALL my reals and ALL my integers throughout my code are similarly defined). I use IMPLICIT NONE everywhere.

In the module, some real variables are defined REAL, PARAMETER :: varname.

Other real variables in the module whose values are derived from PARAMETER values are just defined as REAL(DOUBLE). These variables previously resided in a callback routine in an early version of the program that worked OK. It was a simple single dialog program. My new version uses a tabbed dialog, and I have moved variables previously held in a callback linked to the original dialog into the module and removed them from the callback. The original dialog has become one tab of a 2-tab dialog box. The removed variables are now made available to the callback linked to the first tab by USEing the module that contains them in the callback routine.

When in the debugger, I find that if I enter the name of a parameter variable in MODNAME in the Watch window as MODNAME::varnameparam, the debugger tells me it is undefined. (This is the behaviour I observe even in the program that works OK, so PARAMETER module variable values appear to be out of reach of the debugger in general).

If I enter a non-parameter name MODNAME::varname which has already been defined by previous execution of a statement in a routine that utilises the module parameter values to generate the other values( e.g. varname=varnameparam1*varnameparam2), then a correct value is displayed. It is not flagged as 'undefined'.

If I call a routine with a module parameter variable as an argument, the routine generates very incorrect output values ( I know this because the code has been used in a previous single-dialog (i.e. non-tabbed) project with exactly the same input data where parameters previously resided in a callback function invoked by a button to compute output values. The output generated in the latter case are perfectly sensible).

In teh tabbed-dialog project, when I use the Watch window to examine the arguments after stepping into the called routine, I find that the variable corresponding to the module parameter variable used as argument in the calling program is completely at odds with its actual value defined in the module. This wrong value is clearly used in the called routine and leads to the generation of rubbish output values.

As an example, a run where the first four arguments of a called routine are module variables and the real values observed in the debugger before the call to the routine are 50.02864, 1.972364, -451.50000000, 55.0000000, whereas the real values, as seen in the Locals window, that are assigned to the dummy arguments when I enter the routine are 1.027595374870205D-311, -3.246627407232088D+22, -451.5000000000, 55.000000000

In the called routine, the arguments are defined as either REAL(DOUBLE) or INTEGER(LONG) to match the type of the arguments in the calling program.

P.S. The Tabbed dialog project was converted from a test project created using CompaqVF and I have just noticed that under properties...external procedures, the calling convention is set as CVF (/iface:cvf). I tried changing it to 'Default' and rebuilding and rerunning the debugger, but I got the same behaviour. Using any other options under calling convention gives me link errors.

Problem solved and apologies for wasting your time!

When I stated that I used REAL(DOUBLE) everywhere, I checked again and found that it was not strictly correct!
I found that in one procedure I used REAL(DWORD) for some reason, so I changed all the REAL(DWORD) occurrences to REAL(DOUBLE) and I find now that the module variables are correctly accessed.

(PARAMETER values in a module are still not available to the watch window debugger though, they are still marked as undefined.)


By default, PARAMETER values are not visible to the debugger. You can enable this with Fortran > Debugger > Information for PARAMETER constants

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today