Compiler bug?

[Stuart_M_]

Hi folks

When stepping through my code in VS2005 I find that the compiler is telling me the value for a variable is 1, when in actual fact it is zero when I check it by printing. This occurs after stepping through an IF statement when sets the value to 1 if it's true, and it is NOT true, hence the actual value remaining zero. Anybody know why this happening, or if this is a somewhat common occurance? This is my first knowing experience of this so my trust in the IDE has been shattered considering I've been usingthe values depicted when the cursor is rested on the variableto figure out just what the model is doing.

Incidentally I'm using version 11.0.3454.2005 - I can't seem to find a page to check for updates of the Fortran compiler so not sure if I'm up to date any longer...

[jimdempseyatthecove]

Can you insert the portions of code to illustrate the problem.

One of the usual problems is using a Fortran LOGICAL variable as if it were a C integer or C bool variable.
As an example

If for some reason you have a Fortran LOGICAL (say L) containing a value of 1234 then

IF(L == .TRUE.) ! this is false
IF(L == .FALSE.) ! this too is false

The reason is L is neither the value of .true. nor the value of .false.

Copying a C/C++ bool into a Fortran LOGICAL may present such a condition (neither the value of .true. nor the value of .false.)

Secondly

Comparing REAL for equality and the printed values is not the same. Printing (writing, examining floating point in Watch window) may show rounded values whereas IF(V .EQ. X) compares on exact value.

Jim Dempsey

[Steven_L_Intel1]

Please attach a small (if possible) example that demonstrates the problem. There have been issues in the past where the debugger does not see the correct value.

The version you note is the Visual Studio integration version, not the compiler version, which is shown under Installed Products. It will be prefaced with "Package ID". In any event, 11.0 is not current. If you log into the Intel Registration Center it will show you the latest version you are eligible for. (A word of caution - if you click on the link for a 11.1 compiler it may take you to a download page for 11.0. Use the dropdown box on that page to select 11.1.)

[Stuart_M_]

Hi again

Here's the offending snippet of code, with appropriate variables defined. Stepping through I can check that indeed nbrest=0 when the IF statement is hit. NBND is greater than KBND, and TTREST is 0.0, so both conditions are false. NBREST is shown to be 1 after the check, but printing the value to screen shows it's actually zero still.

INTEGER NBND, NBREST, KBND
REAL*8 TITI, HALFDT
REAL*4 TITI, TTREST

...
NBND = TITI/HALFDT + .5
NBREST= 0
IF ( NBND.LE.KBND .AND. TTREST.NE.0.0 ) NBREST = 1
IF ( NBREST.NE.0 ) THEN
...

[Stuart_M_]

Following up on the software update issue, it seems that the period permitting free upgrades is finite and has expired for me. Am I right in seeing that I have to make a full purchase again in order to be able to download updates?

[Steven_L_Intel1]

It looks as if you have a Student suite license, so yes, your support term expired in April and you'll need to buy again to get updates.

I'll be glad to see if the problem is resolved (or if it is really a bug) if you'll supply a complete test case.

[jimdempseyatthecove]

Were you running the debugger on code with the optmizations enabled? If so, then the variable might not have been written yet (variable cached in register with write to variable memory location later in code sequence).

Jim

[Stuart_M_]

Hi Guys

Sorry - been away a few days.

I'm not sure if I had optimizations enabled - frankly I have never tinkered with that aspect and really know very little about it. Is this a IVF-based configuration or would it originate with Visual Studio? Since we're talking about the IVF compiler I would imagine the former, but like I said, I'm pretty clueless on this front.

On many fronts actually ;-)

Some further observations that might prove useful:

I first discovered the "variable=1 when it actually doesn't" issue when I was trying to use conditional breakpoints. I've since continued to TRY and use this functionality but never with results that I consider consistent, or sensical, leading me to believe that I am either not properly grasping the concept of conditional breakpoints, or not applying them correctly.

In this particular case, I had originally set a breakpt the line below the above-mentioned IF (blah blah) NBREST=1 to hit only when NBREST=1. That is, in the Breakpoint Condition window I ticked "Condition", selected "Is true" and in the text box wrote NBREST=1.

I'm now wondering if this doesn't actually set the variable NBREST equal to 1 if the line of code associated with the breakpoint is true. I wonder this because I've since tried using this with another variable, whose value is read in directly from an input file, by setting a breakpoint with the condition Variable=5. The debugger hits the breakpoint when I know for a fact that the value of the variable is not 5 (that particular line of the input file has DEFINITELY not been reached yet), yet when I check the value of the variable by hovering the mouse over it I'm told the value is what the condition specified (in this case 5, rather than 1 according to the input file). So it almost seems as if the breakpoint condition is changing the value of the variable in the debugger when the breakpoint is hit, not hitting the breakpoint only when the condition specified is met, which is how I've interpreted this functionality based on this text in the Breakpoint Condition window: "When the breakpoint location is reached, the expression is evaluated and the breakpoint is hit only if the expression is true or has changed."

Any thoughts? I can send you guys the solution and source code if you'd like, but it's ~130MB

[IanH]

Make sure you are using the fortran "equal to" operator (== or .eq.) in your condition, not assignment (single =).

I don't know what assignment means in the context of the conditional breakpoint expression evaluator, but I guess what you are seeing could be regarded as "working as designed".

[Steven_L_Intel1]

Is it 130MB after a Build > Clean?

[Stuart_M_]

Quoting - IanH

Make sure you are using the fortran "equal to" operator (== or .eq.) in your condition, not assignment (single =).

I don't know what assignment means in the context of the conditional breakpoint expression evaluator, but I guess what you are seeing could be regarded as "working as designed".

130MB is just the size of the folder containing everything - source code, compiled files, input files etc

The actual code itself is far less, about 30MB including all the object files, but the model won't run without the input files. Thinking about it now though, a bunch of the input files are not used because this is a very simple setup of the model, so it's probably reducible to ~40MB

I'll experiment with == rather than = the next time I try to use the conditional breakpoints... it seems more likely that I'm the one causing hassles than VS messing up.