Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

what's wrong with this IF statement

Brian_Murphy
New Contributor II
2,592 Views

Is there a problem with the following syntax?  Even though IOUT is .false. and IHEAD=1 and ITAIL=400, the code still runs the statement inside the IF.  I can even select the entire expression inside the IF (   )  and the debugger says it evaluates to FALSE.  What the heck is going on?

        IF (IOUT .OR. IHEAD .GT. ITAIL) THEN 
           CALL UMD2ER (1, ICNTL, INFO, -3, INFO (19))
        ENDIF 

 

0 Kudos
23 Replies
Steven_L_Intel1
Employee
2,249 Views

I think we'll need to see a complete test case. There's nothing wrong with the syntax, though I would prefer to see parentheses around the comparison (still, Fortran's precedence rules should have the .GT. evaluated first.)

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

Thanks for the reply, Steve. 

IOUT is declared LOGICAL and IHEAD and ITAIL are INTEGER.

475099

475099  It's a fixed format file, and it's not using any tab characters.  I have it up in the debugger as I write this.  If I select the expression  IOUT .OR. IHEAD .GT. ITAIL  and hover the mouse over it, it shows FALSE, yet execution still goes to the following CALL statement

475099  This code ran fine in Compaq fortran.

I went ahead and put parentheses around  IHEAD .GT. ITAIL but that didn't make any difference.

0 Kudos
mecej4
Honored Contributor III
2,249 Views

The three links in #3 all point to just one file. The code in that file is not complete -- the sources for subroutines umd2er, umd2of, umd2f1 and umd2fb, as well as the source code of the main program, are not provided. Given that this is a report on a perceived debugger problem, it should be possible to first see that problem by running the program under the debugger.

0 Kudos
Steven_L_Intel1
Employee
2,249 Views

Does it actually call UMD2ER, or are you simply seeing the debugger appear to step onto that line?

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

I just checked to be sure, and yes execution is going into UMD2ER.

In my previous post I only attached the file one time.  I have no idea how the post ended up with 3 ?!@#$

The file is just one of hundreds in the project.  There is no MAIN program since the final target is a DLL which is called from Excel VBA.

Are there any project settings in visual studio that can cause this?

0 Kudos
Steven_L_Intel1
Employee
2,249 Views

I looked at the generated code for compiling this without optimization and it looks straightforward to me. I am not sure I would trust what the debugger evaluates the expression as. How about putting in a PRINT inside the IF showing the values of the variables in the expression?

There are no compiler options that should change the behavior.

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

Well I'll be darned.  I put in:   write(9,*) iout, ihead, itail, (IOUT .OR. (IHEAD .GT. ITAIL) )

and got this:      T           1         438 T

So IOUT is TRUE even though the debugger LOCALS window and the popup tip both say FALSE.

Any ideas why this would happen?

I will be backpedaling to figure out why IOUT is true, because with compaq fortran, it was false.  That's won't be as easy as it should be because I can't count on the debugger to show correct variable values.

0 Kudos
mecej4
Honored Contributor III
2,249 Views

Brian Murphy wrote:

That's won't be as easy as it should be because I can't count on the debugger to show correct variable values.

It's actually a bit worse, except when optimizations are turned off. Variables may no longer exist in definite memory locations in optimized code. For example, a loop counter can be held entirely in a register, and there is no memory location attached to the loop variable that the debugger can use to show the value of the variable in the locals window.

Adding print statements alters the generated code, and optimizer bugs often go away when print statements are added to see what may be going on.  At best, a source debugger can only help in the early stages of narrowing down the part of the code where a problem occurs in optimized generated code.

0 Kudos
JVanB
Valued Contributor II
2,249 Views

Could you also print out TRANSFER(IOUT,0) in there? If it's not 0, 1, or -1 that could explain the behavior you observe.

 

0 Kudos
Steven_L_Intel1
Employee
2,249 Views

It could also be that the first time the debugger showed you the IF it was really somewhere else. This is especially possible if you enabled optimization.

RO's suggestion is also good - you want to know what the binary value of IOUT is. Please also copy and paste into a reply the contents of the Fortran > Command Line > All Options pane. RO is probably suspicious that you have an option set that changes the binary values considered true and false.  How is IOUT set in UMD2F1?

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

I changed the write statement to   write(9,*) iout, ihead, itail, (IOUT .OR. (IHEAD .GT. ITAIL) ), transfer(iout,0)

and got this:     T           1         438 T    50332003

I don't know what 50332003 means, but it doesn't look anything like 0, 1 or -1.

Here's the fortran>command line>all options.  The "additional options" field is empty.

/nologo /debug:full /Od /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\SRC\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\UTIL\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\BLAS\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\LAPACK\Win32\Debug" /extend_source:132 /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fp:source /module:"Win32\Debug\\" /object:"Win32\Debug\\" /Fd"Win32\Debug\\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c

I'm going to paste that in again as follows:

/nologo /debug:full /Od /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\SRC\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\UTIL\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\BLAS\Win32\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\LAPACK\Win32\Debug" /extend_source:132 /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fp:source /module:"Win32\Debug\\" /object:"Win32\Debug\\" /Fd"Win32\Debug\\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

In UMD2F1.F the variable IOUT is passed in, declared LOGICAL, initialized to .FALSE. and all the assignment statements for it look like this:

IOUT = IS .GT. ISIZE

I've attempted to attach a file for UMD2F1.f

 

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

How about this.  The VS project to build UMFPACK.LIB was imported from a CVF project, and I see what look like various compatibility options in the Fortran>Command Line string shown in my preceding post.  I'm pretty sure UMFPACK links in 4 other LIB's that I think I created manually instead of by importing.  So they probably have mostly default options set.

Could this cause what is happening?

0 Kudos
JVanB
Valued Contributor II
2,249 Views

No, that can't be the cause. A value such as -2 could result from mixing LOGICAL representations but I don't think 50332003. Also odd values test as .TRUE. for both representations in question.

Instead it could result from mixed-mode arithmetic, compile everything with /stand to see if anything turns up.

Also it could occur as a result of mismatched argument lists, compile with /warn:interfaces to see if that happened.

Also possible is array bounds overrun, especially since your code seems to be doing its own memory management. See if /check:bounds finds any problems.

 

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

Thanks, RO.  I will try those things tomorrow.

In visual studio, is there an easy way to find where to set an option when given something like "/whatever". So far I haven't been able to find /stand.

 

0 Kudos
Kevin_D_Intel
Employee
2,249 Views

One way is to use the Help (?) button on the Properties Pages view to quickly open the Intel Fortran User guide where you can use the search facility. To do this, open the Properties Pages window using either Project > <projectname> Properties -or- via the Solution Explorer, right-click on your Fortran project and select Properties. In the new Properties Pages view that appears, click the small ? in the top-right corner next to the X dismiss button. This button opens the Intel Fortran User guide in another view where you can click Search and then enter the option like /stand. If the option has an IDE Equivalent it will be listed under such in the details for the option.

0 Kudos
IanH
Honored Contributor III
2,249 Views

Brian Murphy wrote:

In visual studio, is there an easy way to find where to set an option when given something like "/whatever". So far I haven't been able to find /stand.
 

Look in the index of (or search) the Fortran compiler help (Help > Intel Compilers and Libraries > Intel Visual Fortran Documentation) for the command line option.  Then on the page for the option see the section titled "IDE equivalent".

To help find out what is clobbering that variable you can use the data breakpoint facility of the debugger (set a breakpoint early in the relevant subroutine, start debugging Excel/your code, when that breakpoint is hit then choose Debug > New Breakpoint > New Data Breakpoint, use LOC(IOUT) as the address)  to break execution when your program attempts to write to the memory that backs IOUT.  Given this is code that interfaces with VBA and has been migrated from CVF, a mismatch in calling conventions should also be added to RO's list.

 

 

0 Kudos
Brian_Murphy
New Contributor II
2,249 Views

Thanks to both.  I will try this later today.  Have other fires to put out this morning.

0 Kudos
Steven_L_Intel1
Employee
2,249 Views

There's clearly a problem with how IOUT is being set. Maybe you have an argument type mismatch or data corruption. I will comment that importing a CVF project doesn't set all those /fpscomp options - they were probably set in the CVF project and I'd expect many are not needed.

The option I don't see is /warn:interface which you should add (Diagnostics > Check Routine Interfaces).

0 Kudos
Brian_Murphy
New Contributor II
2,164 Views

/warn:interface causes several dozen errors #8284 when compiling UMFPACK.LIB  That's why it was turned off.

Error    6     error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [MP]    C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\Umfpack\umd2f0.f    604    

In the above error message, what does [MP] mean?  If this is the offending variable, I cannot find a variable by that name.

It might not be until late tonight or tomorrow that I can get back to this.

0 Kudos
Reply