topic mecej4 it will indeed make it in Intel® Fortran Compiler

warning #7953: meaning

andrew_4619 — Tue, 16 Apr 2013 13:01:58 GMT

I get this warning with standard 2003 setting that I don't understand.

warning #7953: Standard Fortran requires that within a scoping unit, two procedures that have the same generic name shall both be subroutines or both be functions. [$$MSPORTLIB$TIME_S]

this only exists in IPORT in my project as far as I can see. IFPORT has the the interface definitions below but they are not the same

SUBROUTINE $$msportlib$time_s(TIMESTR)

FUNCTION $$msportlib$time_f()

It just seems strange......

This module is not Fortran

Steven_L_Intel1 — Tue, 16 Apr 2013 20:29:37 GMT

This module is not Fortran-standard-compliant because it declares the generic name TIME to be both a function and a subroutine. This is for compatibility with (very) old sources. I would not expect you to get a warning unless you had INTERFACE TIME in your own sources (or you tried to compile the source to IFPORT.)

I had collected a few USE

andrew_4619 — Tue, 16 Apr 2013 23:16:05 GMT

I had collected a few USE statements including USE IFPORT into my own module, does that imply I am trying tio compile it? I do not have any INTERFACE TIME in my own code.

If you just have USE, no you

Steven_L_Intel1 — Tue, 16 Apr 2013 23:36:00 GMT

If you just have USE, no you are not compiling it. I can't come up with an example that gives this error - would you please post or attach one? (Small if possible.) Also tell me which compiler version you're using.

Out of many hundreds of

andrew_4619 — Wed, 17 Apr 2013 01:11:06 GMT

Out of many hundreds of routines the warning occurs in a handful. I look one of these and stripped things away until I was left with 2 lines of code + some decls + use satements. I have attached the source file and the build log (html file renamed to .txt as your uploader will not have it otherwise). If your remove either line of code the warning will go away!

hmm my attached files have

andrew_4619 — Wed, 17 Apr 2013 01:16:36 GMT

hmm my attached files have not appeared so....

[fortran]subroutine pw_cb(dlg,id,cbtype)
use ifwin
use iflogm
use ifport
implicit none
type (dialog) dlg
logical(4) retl4
integer(4) ID,CBTYPE,iochk

retl4=dlgset(dlg,1130,.false.,DLG_ENABLE)
open(15,file='fred.par',status='old',iostat=iochk)
return
end[/fortran]

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.0.149 [IA-32]... ifort /nologo /O3 /I"Release/" /stand:f03 /Qdiag-disable:5142,7025 /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:uncalled /warn:interfaces /Qauto_scalar /module:"Release/" /object:"Release/" /Fd"Release\vc100.pdb" /libs:qwin /c /Qvc10 /Qlocation,link,"c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\\bin" "......\Source1.f90" C:\......\Source1.f90(4): warning #7953: Standard Fortran requires that within a scoping unit, two procedures that have the same generic name shall both be subroutines or both be functions. [$$MSPORTLIB$TIME_S] use ifport

Removing the /stand:f03

mecej4 — Wed, 17 Apr 2013 01:38:02 GMT

Removing the /stand:f03 option makes the problem go away. It appears that when the option is used the compiler is able to check for interface consistency based on information in the .mod files.

mecej4 it will indeed make it

andrew_4619 — Wed, 17 Apr 2013 01:46:57 GMT

mecej4 it will indeed make it go away as will adding an ignore 7953 instruction. I don't understand why i should get the warning in some cases and not others. It does not make much sense. I don't buy the mod file comment as the mod files are not changing. 700+ routines give no warning 30 or so do, all will the same use statements. There is an element of what is in the code part of the subroutine that triggers the warning.

This has got to be a compiler

Steven_L_Intel1 — Wed, 17 Apr 2013 16:38:00 GMT

This has got to be a compiler bug. I will let the developers know. Thanks for the short example. Issue ID is DPD200243368.

This is fixed for a release

Steven_L_Intel1 — Fri, 11 Apr 2014 16:00:53 GMT

This is fixed for a release later this year.