- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply, Steve.
IOUT is declared LOGICAL and IHEAD and ITAIL are INTEGER.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does it actually call UMD2ER, or are you simply seeing the debugger appear to step onto that line?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Brian Murphy wrote: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.
That's won't be as easy as it should be because I can't count on the debugger to show correct variable values.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Brian Murphy wrote: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".
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to both. I will try this later today. Have other fires to put out this morning.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page