How to get rid of GHOST entry point ?

[WSinc]

I decided to change a FUNCTION into a SUBROUTINE call.

But then it kept insisting that I was "calling a function as a subroutine."

Changing the source code file name did not help, neither did a

CLEAN and Rebuild, nor did deleting and recreating it.

Even when I removed the routine entirely, I got the same message, rather

than getting "entry point not found."

Shouldn't entirely removing a routine cause an unsatified entry point? Not in this case, anyway....

Tried restarting VS 2008, no changes there.

The only thing that cured it was - changing the name of the entry point.

Apparently I can never use the old entry point again, no matter what.

What causes this? Is there a fix?

[Steven_L_Intel1]

This is a side effect of generated interface checking. Sometimes, the old interface stays around after you change the routine. Do a rebuild and it should go away.

[WSinc]

That was one of the first things I did.

But, it had no effect.

The only thing that works (so far) is to change the name of the entry point.

Is there a way to attach the entire project build?

[Steven_L_Intel1]

You can attach a ZIP of the project folder. Do a Build > Clean first.

[WSinc]

Is there a way to get the full path name of all the source files included?

The solution space only gives the file names, not where they came from.

I want to make sure all the files are within the same folder.

Do you want just the source files, or the GENMODS and OBJECT files as well?

By the way, an include statement does not work if the file to be included is outside the project folder.

Is that part of the specs?

[Steven_L_Intel1]

The project file (.vfproj) gives the path to the source files. Usually this is a relative path (relative to the project folder) but it could be absolute. If your source files are in a folder separate from the project, then if you attach the project the paths will likely be invalid, though I can fix that if you also attach the files.

INCLUDE by default looks in the same folder as the source file with the INCLUDE statement, plus any folders listed in the INCLUDE environment variable and any folders specified with the /I command line option. You can add INCLUDE folders in the project properties. Compiled modules are looked for in the same places.

If you say a rebuild does not solve the problem, then I don't need the .mod and .obj files.

[WSinc]

Well, as far as the INCLUDE file goes:

It was a common block that I had specifically added to the project as a "New item."

So the Solution space (Ctl-R) view shows that it's there in the project -

But the INCLUDE statement still can't find it when I invoke the compiler.

Should it be in the RESOURCE files? That isn't clarified anywhere that I can find.

[Steven_L_Intel1]

Adding an INCLUDE file to the project doesn't help the compiler find it - it just lets you easily edit it. From Visual Studio, the compiler will look in the folder containing the source file, the project folder, folders you listed as "additional INCLUDE directories" and those listed under Tools > Options > Intel Fortran > Compilers > Include Files.

INCLUDE files would be more reasonably categorized under Header Files (Resource Files are for dialogs, controls, etc.)

[WSinc]

Ok Steve;

Here is the whole thing - I decided to "play it safe," and include the solution spce also.

The problem is with the main program (extprec) line 39.

If you uncomment that, the build will not complete, since it somehow thinks the old entry point is present.

I think that somehow the project or solution file got "poisoned" and it thinks the entry point is still present,

even when there are no source or object modules correcponding to it (MULTINV). So a clean and rebuild has NO effect.

Probably if I started the project from scratch with just the source code, the problem would disappear.

Is there a quick way to do that? The VS2008 will only allow me to add one module at a time.

So here's the archived file -

[Steven_L_Intel1]

You declared multinv as integer in extprec.f90, which makes it a function. Remove multinv from that declaration and the problem goes away.

You can shift-select or ctrl-select multiple source files in the add-to-project dialog.

[WSinc]

I don't understand -

Why does the compiler think it's somthing special?

That could have been any other variable that never got used, for example.

I don't use it anywhere else, so why would it think it's a function, and give it

special treatment?

Does the CALL statement do something weird? That only refers to subroutines, right?

[IanH]

In the absence of modules or interface checking trickery, within each program unit the compiler knows absolutely nothing about multinv, other than what you tell it. Working from the top of your source - you gave multinv a type. Subroutines don't have a type, therefore multinv can't be a subroutine (if its got a type it's got to be a function or a variable **). If it's not a subroutine, you can't call it, and so the attempt to do so results in the error that you see.

(** s16 of the F2003 std talks about scope of names etc, and prohibits having the same name for a variable and an external procedure in general in the same scope - multinv can't be both a variable and a function/subroutine at the same time in the same scope, or compiler writer's heads would explode with the potential ambiguities.)

The simplest fix is to put your functions and subroutines into modules and have the appropriate USE statements in the procedures that use those functions and subroutines. Then the compiler knows exactly what each name refers to, without any further effort on your part. A whole lot of other goodies get thrown into the bargain too.

[Steven_L_Intel1]

The CALL statement expects a procedure. If the name of the thing you are calling has been given a type, that means it's a function. Often in Fortran the "class" of a name doesn't get locked in until it is used in some particular context. For example, if the name had been used in an assignment statement, it would be a variable and couldn't be referenced as either a subroutine or function.