Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

warning #7953: meaning

andrew_4619
Honored Contributor III
1,403 Views

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......

0 Kudos
9 Replies
Steven_L_Intel1
Employee
1,403 Views

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.)

0 Kudos
andrew_4619
Honored Contributor III
1,403 Views

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.

0 Kudos
Steven_L_Intel1
Employee
1,403 Views

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.

0 Kudos
andrew_4619
Honored Contributor III
1,403 Views

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!

0 Kudos
andrew_4619
Honored Contributor III
1,403 Views

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

0 Kudos
mecej4
Honored Contributor III
1,403 Views

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.

0 Kudos
andrew_4619
Honored Contributor III
1,403 Views

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.

0 Kudos
Steven_L_Intel1
Employee
1,403 Views

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

0 Kudos
Steven_L_Intel1
Employee
1,403 Views

This is fixed for a release later this year.

0 Kudos
Reply