CVF Compile Errors on MSFP Code

CVF Compile Errors on MSFP Code

I apologize if all of this posting appears to be really wide in your browser. I don't know why that happened to my regular text and not just to the code text. Can anyone tell me what I'm doing wrong?

I'm using CVF 6.6B on Windows XP Pro. I am trying to get some code that was originally developed with Microsoft FORTRAN PowerStation 1.0a (a /= alpha, actually an update to v1.0) to compile properly with CVF.

I've fixed most of the problems, but I'm stuck on the two remaining ones.

This code comes with a .lib library file that I think was also created with MSFP. It contains what I believe are some display routines that allow the program to display graphics when run. I added the .lib file to my VS project.

The original code declared all of the references to the library routines like this:

integer*4 GetMouseEvent[EXTERN]

That generated compilation errors for each declaration. I changed the declarations to this format:

integer*4, external:: GetMouseEvent

That took care of all the errors except for the one about the GetMouseEvent routine. The error message for it is:

S:DeveloperStudioTXSUTIL.FD(181) : Error: This name has already been used as an external procedure name.   [GETMOUSEEVENT]
      integer*4, external::  GetMouseEvent

I tried to figure out why the compiler treated GetMouseEvent differently. I couldn't find anything in the code, so I used the DUMPBIN utility on the .lib file. Part of the DUMPBIN output is:

   .data name
       0 physical address
       0 virtual address
      20 size of raw data
     5F6 file pointer to raw data (000005F6 to 00000615)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
  300040 flags
         Initialized Data
         4 byte align

000 00000000 DEBUG  notype       Filename     | .file
002 00000000 SECT1  notype       Static       | .text
    Section length  592, #relocs   51, #linenums    0, checksum        0
004 00000000 SECT2  notype       Static       | .data
    Section length   20, #relocs    0, #linenums    0, checksum        0
006 00000000 ABS    notype       Static       | FLAT
007 00000000 SECT1  notype       External     | _MOUSEINIT@0
008 000002F8 SECT1  notype       External     | _GETBUTTONPRESS@4
009 000003AB SECT1  notype       External     | _GETBUTTONRELEASE@4
00A 0000045E SECT1  notype       External     | _SETPTRVIS@4
00B 0000049A SECT1  notype       External     | _SETPTRXLIM@8
00C 00000516 SECT1  notype       External     | _SETPTRYLIM@8
00D 000001CD SECT1  notype       External     | _GETPTRPOS@4
00E 0000027C SECT1  notype       External     | _SETPTRPOS@8
00F 00000000 UNDEF  notype       External     | __getvideoconfig
010 000000E5 SECT1  notype       External     | _GETMOUSEEVENT@4

String Table Size = 0x9C bytes


          20 .data
         608 .text

I can see GetMouseEvent listed, but it comes after the line for __getvideoconfig, and that line has UNDEF (for undefined?) where every other line has SECT1. Is that significant? Can anyone suggest why I'm seeing the error for the GetMouseEvent routine?

There is one other error I can't figure out. The code contains a call to SETTEXTPOSITION. Compilation produces the error:

S:DeveloperStudioTXSOpConSb1.for(1619) : Error: There is no matching specific subroutine for this generic subroutine call. [SETTEXTPOSITION]
call settextposition (row0(isel),col0,tx)
I built this program as a console application (because I wasn't sure what it should be), and the routine containing the call to SETTEXTPOSITION originally didn't contain a USE DFLIB statement. When I put in that statement it caused several other errors, a sample of which is below:

C:Program FilesMicrosoft Visual StudioDF98IncludeDFLIB.F90(47) : Error: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit.   [ARC]
 FUNCTION arc(x1,y1,x2,y2,x3,y3,x4,y4)

This error refers to the following INTERFACE block in the DFLIB.F90 file:

	FUNCTION arc(x1,y1,x2,y2,x3,y3,x4,y4)
	  INTEGER*2 arc,x1,y1,x2,y2,x3,y3,x4,y4
!DEC$ ATTRIBUTES C,ALIAS:"__arc" ::  arc
	  INTEGER*2 arc,x1,y1,x2,y2,x3,y3,x4,y4
!DEC$ ATTRIBUTES C,ALIAS: "_arc" ::  arc

I also tried building the code as a graphics project since it uses graphics, but that made no difference in the results.

Can anyone help me determine the causes of these two errors?


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

I think I solved my problems.

The error messages for GetMouseEvent disappeared when I deleted the declarations for it, but I don't understand why.

As for the other error for SETTEXTPOSITION, I finally determined that its interface in DFLIB.F90 defines it as a generic routine. Once I changed my


statements to


all the errors disappeared.

I still have to test the executable and see how it runs.


The program begins to run and then crashes with an access violation, so I'm trying to debug it. Something seems wrong, though. Variables aren't showing their values when I place the cursor over them, and several of the variables in the locals window show an error message where the values should appear, "Error: cannot display values."

Can anyone tell me what's wrong?


Are you compiling with optimization enabled? That can impair debugging.


Steve - Intel Developer Support

No, I'm not compiling with optimization enabled. I'm using a debug configuration with the debug setting at "full" in the Fortran project settings.


I've found more strangeness as I try to debug this program.

I've noticed that the Data Tips do work to show me the values of only a few select variables when I hover my cursor over them. They're always the character data type, but only a few work.

I've also noticed something strange about the values displayed in the Locals window. For example, my program has three CHARACTER*8 variables that are present as the only contents of a COMMON block. They are listed in the Locals window one after the other, but they show up as eight-element single-character arrays with the plus sign enclosed in a box to their lefts. I can click on the box and expand the "array." Three consecutive assignment statements fill these variables with data. The first assignment seems normal, but after the second assignment the first variable contains both values. After the third assignment the first variable contains all three values, and the second variable contains the second and third values. There is a hexidecimal value to the left of the character data in the Value column.

The first variable looks like:

+ VAR1   0x00c26d40 "abcdefg ijklmno qrstuv "

The second variable looks like:

+ VAR2   0x00c26d48 "ijklmno qrstuv "

The third variable looks like:

+ VAR3   0x00c26d50 "qrstuv "

The Data Tips work for all three of these particular character variables.

In another instance, an INTEGER*2 variable appears in the Locals window as a one-element array with much the format as the character variables above. Data Tips doesn't work for this variable, though.

Another thing I've noticed is that no variable I drag to the Watch window will show its value unless Data Tips works for it when I place my cursor over it. So, for example, the Watch window works for VAR1 above, but not the INTEGER*2 variable. In the Watch window's Value column the display for the INTEGER*2 value is:

CXX0017: Error: symbol "varname" not found

This happens even though I have the Fortran project setting Generate Browse Source Information checked.

I've tried to build this project a couple of different ways because I don't know what the original MSFP project type was. The effects I described above are for a QuickWin project.

Does this additional information give anyone clues about what I'm seeing?

Is there any rhyme or reason to the order in which variables appear in the Locals window? I sure would prefer to see them in alphabetical order.

By the way, my IE 5.5 browser sees all of my postings and the replies as single-line paragraphs that stretch off to the right past the edge of my screen. What did I do that made this happen?


Your replies look fine to me.

A couple of things to mention:

1. Source browse info has no connection with debugging. That's for the Source Browser feature (right click on symbol name, select Go To Definition, etc.)

2. From the symptoms you're describing, my best guess is that you have not run Per-User Setup, as instructed by Getting Started as a post-installation task. Start..Programs..Compaq Visual Fortran 6..Per-User Setup. Do that, restart Developer Studio, see what happens.

3. The odd display of the character variables is the way the C debug expression evaluator does it, which is what prompts me to suggest 2 above. It also explains some other things you described.


Steve - Intel Developer Support

Oh, the order of variables in the Locals window is unpredictable - my guess is that it's the order in which the debugger sees the symbols in the symbol table. Nothing CVF can do about that.

Steve - Intel Developer Support

I'm positive that I've run Per-User Setup before, but I did it again from my user account and from the Administrator account. I also rebooted my system. None of that made any difference.

I see what you mean about the C expression evaluator being active instead of the Fortran expression evaluator. For example, when I look at the call stack the arguments are listed as long *, double *, etc. I thought that there was a setting to switch between the two evaluators, but I can't find one.

Do I need to go into the Windows Registry and manually reset a key to get myself out of this?


Before I started working with this Fortran program I opened and ran MSVC++ 6.0 to compile and link some C source code for someone who didn't have a C compiler. Would that have reset some internal VS setting that is now affecting CVF?


No, doing a VC++ build would have no effect.

The registry key is HKEY_CURRENT_USERSoftwareMicrosoftDevStudio6.0Build SystemComponentsPlatformsWin32 (x86)Expression EvaluatorsCurrent EE - value should be EESWT.


Steve - Intel Developer Support

It worked! The orignal registry value was EECXX. I changed it to EESWT, and the debugger behavior is back to normal.

Thank you very much, Steve. Do you have any idea what could have changed the registry key value? Whatever it was, I certainly don't want to do it again.

My last post about the messages was irrelevant. Those same messages appear in the Debug window now.


Installing MSVC or a service pack would reset it.

The messages are just informational saying that you don't have debug symbols for those system DLLs - ignore them.


Steve - Intel Developer Support

Here's another symptom to consider. When I start to execute the program under control of the debugger the Debug window contains multiple messages of the form:

Loaded 'ntdll.dll', no matching symbolic information found.

There are several of these messages, naming files like:



Leave a Comment

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