Is this a compiler bug?

[WSinc]

[plain]This is something I've done many times before in earlier versions of Fortran. Now for some reason it doesn't like me to take the DOT PRODUCT of two 3-vectors. I am giving it the name of a 3-vector here as an input.
Does this have to do with the real*16 typing?

I get these error messages:






Error	1	 error #6637: This actual argument must be the name of an external user function or the name of an intrinsic function.   [XYZ]	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	20	
Error	2	 error #6637: This actual argument must be the name of an external user function or the name of an intrinsic function.   [XYZ]	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	20	
Error	3	Compilation Aborted (code 1)	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	1

    program Geoid
    implicit none
    ! Variables
    real*16 dot,a,b,asq,bsq,vel,vsq,lamda,&
            sdot,sdotsq,udot,vdot,vdotsq,udotsq,&
            u,v,su,sv,c2u,s2u,c2v,s2v,cu,cv,Tke,fun1,&
            xyz(3),xyzd(3)
    ! Body of Geoid
    data u,v,udot,vdot/0.4,0.3,0.7,0.9/
    print *,"input vel, lamda(deg)="
    read *,vel,lamda
    udot=vel*cosd(lamda)
    vdot=vel*sind(lamda)
    xyz(1)=a*cos(u)*cos(v)
    xyz(2)=a*sin(u)*cos(v)
    xyz(3)=b*sin(v)
    xyzd(1)=-a*(udot*sin(u)*cos(v)+vdot*sin(v)*cos(u))
    xyzd(2)= a*(udot*cos(u)*cos(v)-vdot*sin(u)*sin(v))
    xyzd(3)= b*vdot*cos(v)
    vsq=dot(xyz,xyz) ! why do I get an error #6637 here?
    print 101,"vsq=",vsq
    Tke= fun1(u,v,udot,vdot)
    print 101,"Tke=",Tke
101 format(1x,a,T8,f20.12)
    pause "exiting  - - -" 
    end program Geoid
    
    real*16 function dot(x,y)
    real*16 x(3),y(3)
    dot=x(1)*y(1)+x(2)*y(2)+x(3)*y(3)
    end function dot

	
[/plain]

[TimP]

Technically, dot should be declared external,or moved to a CONTAINS section or MODULE. If your previous compilers had the opportunity to check, and didn't detect this, thatcould be considered a bug. If you are getting this check by /gen-interfaces it would be possible, although undesirable, to turn it off.

[WSinc]

Quoting - billsincl

[plain]This is something I've done many times before in earlier versions of Fortran. Now for some reason it doesn't like me to take the DOT PRODUCT of two 3-vectors. I am giving it the name of a 3-vector here as an input.
Does this have to do with the real*16 typing?

I get these error messages:






Error	1	 error #6637: This actual argument must be the name of an external user function or the name of an intrinsic function.   [XYZ]	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	20	
Error	2	 error #6637: This actual argument must be the name of an external user function or the name of an intrinsic function.   [XYZ]	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	20	
Error	3	Compilation Aborted (code 1)	C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90	1

    program Geoid
    implicit none
    ! Variables
    real*16 dot,a,b,asq,bsq,vel,vsq,lamda,&
            sdot,sdotsq,udot,vdot,vdotsq,udotsq,&
            u,v,su,sv,c2u,s2u,c2v,s2v,cu,cv,Tke,fun1,&
            xyz(3),xyzd(3)
    ! Body of Geoid
    data u,v,udot,vdot/0.4,0.3,0.7,0.9/
    print *,"input vel, lamda(deg)="
    read *,vel,lamda
    udot=vel*cosd(lamda)
    vdot=vel*sind(lamda)
    xyz(1)=a*cos(u)*cos(v)
    xyz(2)=a*sin(u)*cos(v)
    xyz(3)=b*sin(v)
    xyzd(1)=-a*(udot*sin(u)*cos(v)+vdot*sin(v)*cos(u))
    xyzd(2)= a*(udot*cos(u)*cos(v)-vdot*sin(u)*sin(v))
    xyzd(3)= b*vdot*cos(v)
    vsq=dot(xyz,xyz) ! why do I get an error #6637 here?
    print 101,"vsq=",vsq
    Tke= fun1(u,v,udot,vdot)
    print 101,"Tke=",Tke
101 format(1x,a,T8,f20.12)
    pause "exiting  - - -" 
    end program Geoid
    
    real*16 function dot(x,y)
    real*16 x(3),y(3)
    dot=x(1)*y(1)+x(2)*y(2)+x(3)*y(3)
    end function dot

	
[/plain]

Hello Tim;

I put the EXTERNAL statement in as you suggested, and moved the DOT function to another file separately.
But I still get the exact same error messages.
If the DOT function was originally in the same source file module, why would the interface be a problem?

[WSinc]

Quoting - billsincl

Hello Tim;

I put the EXTERNAL statement in as you suggested, and moved the DOT function to another file separately.
But I still get the exact same error messages.
If the DOT function was originally in the same source file module, why would the interface be a problem?

By the way, I noticed that the function FUN1 does NOT generate these same errors, and it has the exact same usage as DOT.

So, is there something special about the name DOT that might confuse the compiler?

Anyway, FUN1 works fine, and I didn't have to take any of those extra steps.

[WSinc]

Quoting - billsincl

By the way, I noticed that the function FUN1 does NOT generate these same errors, and it has the exact same usage as DOT.

So, is there something special about the name DOT that might confuse the compiler?

Anyway, FUN1 works fine, and I didn't have to take any of those extra steps.

To further elucidate this weirdness, I changed the function name to DOTX, and it works fine.....
NO MORE ERROR MESSAGES.

But when I scanned the name DOT with the F1 key, it does mention a "transformational intrinsic function" called DOT_PRODUCT. So, I was wondering if the name might be confusing the compiler.

This is a new one on me. Is that "transformational intrinsic function" a recent addition?

[TimP]

Quoting - billsincl

To further elucidate this weirdness, I changed the function name to DOTX, and it works fine.....
NO MORE ERROR MESSAGES.

But when I scanned the name DOT with the F1 key, it does mention a "transformational intrinsic function" called DOT_PRODUCT. So, I was wondering if the name might be confusing the compiler.

This is a new one on me. Is that "transformational intrinsic function" a recent addition?

dot_product was introduced in f90. If Visual Studio or ifort is confusing it with dot, that's a bug. I think BLAS95 headers would include a definition of DOT generic function, but that ought to affect you only if you were USEing that header.

[Steven_L_Intel1]

I can't reproduce this with 11.0.066 or 10.1.026. Please show the command line and all the output from the ifort command you are using.

[jimdempseyatthecove]

Quoting - billsincl

Hello Tim;

I put the EXTERNAL statement in as you suggested, and moved the DOT function to another file separately.
But I still get the exact same error messages.
If the DOT function was originally in the same source file module, why would the interface be a problem?

In your original program with errors...
What happens if you change real*16 to real*8?

Not that you want to run that way, but just as a test.

Jim Dempsey

[WSinc]

Quoting - Steve Lionel (Intel)

I can't reproduce this with 11.0.066 or 10.1.026. Please show the command line and all the output from the ifort command you are using.

That is what came from the buildlog.htm - Is that what you need?
I converted all the real*16 variables to real(8) first, but I still get these crpytic error messages.
I don't see how I can get this when ALL the variables are the same type.
I'm using the VS 2008 interface, I don't use IFORT directly.
See below.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Compiling with Intel Fortran 11.0.066 [IA-32]...
ifort /nologo /debug:full /Od /gen-interfaces /warn:interfaces /module:&quotDebug" /object:&quotDebug" /traceback /check:bounds /libs:static /threads /dbglibs /c /Qvc9 /Qlocation,link,&quotC:Program FilesMicrosoft Visual Studio 9.0VCbin" &quotC:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90"
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(26): error #7977: The type of the function reference does not match the type of the function definition. [DOTX]
vsq=dotx(xyzd,xyzd)
^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(26): error #6633: The type of the actual argument differs from the type of the dummy argument. [XYZD]
vsq=dotx(xyzd,xyzd)
-------------^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(26): error #6633: The type of the actual argument differs from the type of the dummy argument. [XYZD]
vsq=dotx(xyzd,xyzd)
------------------^
compilation aborted for C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90 (code 1)


Geoid - 4 error(s), 0 warning(s)

[Steven_L_Intel1]

Ah. Do a Build > Clean on the solution and then build again. You may be hitting stale generated interface modules. Have you recompiled the source defining function DOTX?

[WSinc]

Quoting - Steve Lionel (Intel)

I can't reproduce this with 11.0.066 or 10.1.026. Please show the command line and all the output from the ifort command you are using.

I changed all the variables back to real(16), but then I get the same error messages on a DIFFERENT line. This time its line 28, instead of line 26. So that's a different function call.

I have to conclude that something is very screwed up with the way they set up their interface checking. How do I turn it off?
Of course, unfortunately it won't then catch interface errors that I create.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Build started: Project: Geoid, Configuration: Debug|Win32

Output


Compiling with Intel Fortran 11.0.066 [IA-32]...
ifort /nologo /debug:full /Od /gen-interfaces /warn:interfaces /module:&quotDebug" /object:&quotDebug" /traceback /check:bounds /libs:static /threads /dbglibs /c /Qvc9 /Qlocation,link,&quotC:Program FilesMicrosoft Visual Studio 9.0VCbin" &quotC:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90"
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(28): error #7977: The type of the function reference does not match the type of the function definition. [FUN1]
Tke= fun1(u,v,udot,vdot)
^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(28): error #6633: The type of the actual argument differs from the type of the dummy argument.
Tke= fun1(u,v,udot,vdot)
--------------^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(28): error #6633: The type of the actual argument differs from the type of the dummy argument.
Tke= fun1(u,v,udot,vdot)
----------------^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(28): error #6633: The type of the actual argument differs from the type of the dummy argument. [UDOT]
Tke= fun1(u,v,udot,vdot)
------------------^
C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90(28): error #6633: The type of the actual argument differs from the type of the dummy argument. [VDOT]
Tke= fun1(u,v,udot,vdot)
-----------------------^
compilation aborted for C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsGeoidGeoidGeoid.f90 (code 1)


Geoid - 6 error(s), 0 warning(s)

[WSinc]

Quoting - Steve Lionel (Intel)

Ah. Do a Build > Clean on the solution and then build again. You may be hitting stale generated interface modules. Have you recompiled the source defining function DOTX?

Well, of course every time I change the variable definitions, it recompiles every one of the modules, since the source code is modified.

But, as you suggested, the CLEAN works - I got no more error messages. So I guess we should assume that we should ALWAYS do a clean before each build to keep this problem from rearing its ugly head. That will of course recompile every module every time.

It seems to be the only way to prevent it anyway, at least for now, unless we want to suppress the interface checking.

[tropfen]

Hello,

based on this thread i have a question.

In the example there is declared a function dot. There is also declared a variable dot inside the program which is calling the function dot.

Do i have to delcare those variable or is it optinal? May it depend on the cirumtances?

The reason for my question is simple. Nearly every time i reuse programs and functions from other persons, i have the remove the declaration of the varibale dot. If not i will get a compiling error.

I am using IVF 10.1.024 and free(*.f90) style.

Thanks in advance
Frank

[Les_Neilson]

Quoting - tropfen

Hello,

based on this thread i have a question.

In the example there is declared a function dot. There is also declared a variable dot inside the program which is calling the function dot.

Frank
The"real*16 dot,..."in the main program is telling the compiler (and the reader) the size of dot, which may or may not be an actual variable.
The compiler determinesfrom theuse of dot later in the code that itis a function call (which is what the "external" statement would tell us) and that the return valuewill then be of size real*16.
This is one reason why my preferred style is one variable per line with all the attributes with it :
real*16, external :: dot
(I also like to gather variables of the same type together, but maybe I'm just fussy)
though I realise that when working with legacy code (as I do a lot) this is not always possible to "fix" (eg if the code is "owned" by someone else)

Les

[Steven_L_Intel1]

You should not have to do a clean unless you have changed the arguments to a routine and you see unexpected errors. Most of the time this works out just fine.

[bmuirpurdue_edu]

I cannot start a new thread, keep getting a web page error. But I can reply to a thread, and this one seemed similar so here goes

I am having a similar problem as others with the rc.exeerror, but solutions/problems identified do not seem to fit my case.

I am logged in a administrator, running Vista with all updates and SP1. the Intel Fortran compiler version "Intel Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.0.3452.2008", developed with Visual Studio 2008 V9.021022.8 Net Framework V 3.5

I tried to compile the example code include (Console3) which is a very simple program with results below. Note the WindowsSdkDir path exists, but the is no rc.exe file in the bin or anyplace on my computer.

Thank you for your help.

1>------ Build started: Project: Console3, Configuration: Debug x64 ------
1>rc.exe not found.
1>Project : warning PRJ0018 : The following environment variables were not found:
1>$(WindowsSdkDir)
1>
1>Build log written to "file://C:UserstestDocumentsVisual Studio 2008ProjectsConsole3Console3x64DebugBuildLog.htm"
1>Console3 - 1 error(s), 0 warning(s)