Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

strange warnings

Robert_van_Amerongen
New Contributor III
564 Views
The following code, compiled with the /stand:f03 option, produces two warnings. The code:

[bash]  INTEGER FUNCTION Bepaal_aantal_processoren()
!
!  This function returns the number of processors by calling
!  GetSystemInfo
!  9 augustus 2010
!  30 november 2010
!
  USE IFWIN
  IMPLICIT none
  TYPE(T_SYSTEM_INFO) :: si
  CALL GetSystemInfo(si)
  Bepaal_aantal_processoren = si%dwNumberOfProcessors
  RETURN
  END  [/bash]

The first warning is #6463. The compiler tells methat T_SYSTEM_INFO is not a derived type name. And the second warning is #6135 where the compiler suggest me to use si.dwNumbers.. in stead of si%dwNumbers.. He interprets this as a DEC Fortran field.
These are warnings, no errors. The compiler compiles fine and so run the program. Compiling without the /stand:f03 option produces no warnings at all.

This seems strange to me. What's going on here?

Robert
0 Kudos
3 Replies
Steven_L_Intel1
Employee
564 Views
The compiler is correct on both counts. What you are missing is that T_SYSTEM_INFO is defined in IFWINTY using the DEC STRUCTURE/RECORD extension and not a Fortran 90 TYPE. And this is because the type needs to have a UNION, which Fortran standard types do not allow.

So the first warning is saying that you used the TYPE() construct for a STRUCTURE. Intel Fortran supports this, but it is an extension. The second warning is that you are using the % separator when referencing a STRUCTURE - again an extension.
0 Kudos
Paul_Curtis
Valued Contributor I
564 Views
... the type needs to have a UNION, which Fortran standard types do not allow.

Yeah it's always a bummer when Intel does this. In fact Windows cares not at all what sort of internal definitions are present in the passed argument, only that it has the correct size. From the pov of the calling program, the only requirement is that the correctly TYPEd internal components (ie, the ones you want) are present at the correct offsets within the argument.

So the easiest solution to this sort of problem is to create a custom TYPE object (ie, not a STRUCTURE) and simply eliminate the UNIONed components (choose one mapping only) which you probably weren't going to use anyway. To go with this, disable Intel's supplied interface and create your own interface to the API function which references the new TYPE.

[bash]TYPE better_system_info
   integer(WORD) wProcessorArchitecture
   integer(WORD) wReserved
   integer(DWORD) dwPageSize ! knowns  DWORD 
   integer(LPVOID) lpMinimumApplicationAddress ! knowns  LPVOID 
   integer(LPVOID) lpMaximumApplicationAddress ! knowns  LPVOID 
   integer(pointer_len) dwActiveProcessorMask ! typedefs  DWORD_PTR 
   integer(DWORD) dwNumberOfProcessors ! knowns  DWORD 
   integer(DWORD) dwProcessorType ! knowns  DWORD 
   integer(DWORD) dwAllocationGranularity ! knowns  DWORD 
   integer(WORD) wProcessorLevel ! knowns  WORD 
   integer(WORD) wProcessorRevision ! knowns  WORD 
END TYPE better_system_info[/bash]

0 Kudos
Robert_van_Amerongen
New Contributor III
564 Views
Steve and Paul,

thanks for the reply. I am not familiair with DEC Fortran and this Intel extension. Whatever you like or do not like on this issue, the "strange behaviour" is clarified! I will ignore these warnings in the future.

Again thanks!

Robert
0 Kudos
Reply