New internal compiler error in release 10.0.027

[van_der_merwe__ben]

Hi, we are considering upgrading from Intel Fortran 9.1 to 10.0.027 (running on Windows XP, IA32). This is for a commercial application.

All of the code compiles fine under the new version, except that some files now generate internal compiler errors.

Any suggestions or work arounds please?

ifort.exe @x.fcf LibLoadLib.f90

ifort.exe @x.fcf Libcallback.for
fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for Libcallback.for (code 1)

The files are as follows:

x.fcf:

/Zi
/Od
/W1 /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /c
/nologo /warn:nofileopt /Qzero /Qsave /align:rec1byte
/check:bounds
/iface:mixed_str_len_arg
/include:"c:PROGRA~1intelcompilerfortran100~1.027ia32Include"
/check:bounds /debug:full /dbglibs /compile_only /dll /threads /assume:byterecl /libs:dll


LibLoadLib.f90:

module LibLoadLib

integer :: iPointer
pointer (pASYGET,lib_asyget)

public LibSetup

interface
SUBROUTINE LIB_ASYGET(IASSAY)
INTEGER IASSAY
END SUBROUTINE LIB_ASYGET
end interface

contains
subroutine LibSetup
! pASYGET = GetProcAddress...
end subroutine

end module

libcallback.for:

subroutine Lib_Asyget (ASSNO)
use LibLoadLib
integer ASSNO

call LibSetup
if(pASYGET.gt.0) then
call Lib_Asyget (ASSNO)
endif
end

[Steven_L_Intel1]

The code is illegal - you can't have LIB_ASYGET be both a pointee in the module and the name of the subroutine in which the module is used.

You can avoid the internal compilation error by moving the POINTER statement to after the INTERFACE block (please do report this!) but you're still going to have to fix the conflict issue.

My guess is that your real code doesn't have the conflict (it was created when you typed in the example) and that the real problem is the position of the POINTER statement.

[van_der_merwe__ben]

Ahhh.... Let me go and look at the real files which I think will have the same problem.If so, I may be able to fix it easily. Right now this keeping everyone else in the group from updating.

Thanks!

(FYI: This does compile and run fine under the old Compaq and Intel 9.1.)

[Steven_L_Intel1]

Yes, I verified that it used to work. When you report this to Intel Premier Support, please reference T80039-CP.

[van_der_merwe__ben]

Thank you kindly, Lionel!

The naming conflict also exists in the much larger source file that I used to produce this example (we have lots of old Fortran code written by many people).

Changing the code to look like the code below, as per your suggestion, seems to compile fine.

I shall go and fix this in the original source files and see how it goes.

module LibLoadLib

public LibSetup

interface
SUBROUTINE LLIB_ASYGET(IASSAY)
INTEGER IASSAY
END SUBROUTINE LLIB_ASYGET
end interface

integer :: iPointer
pointer (pASYGET,llib_asyget)

contains
subroutine LibSetup
! pASYGET = GetProcAddress...
end subroutine

end module

and

subroutine Lib_Asyget (ASSNO)
use LibLoadLib
integer ASSNO

call LibSetup
if(pASYGET.gt.0) then
call LLib_Asyget (ASSNO)
endif
end

[Steven_L_Intel1]

That looks good. The only part that gives me pause is the "integer iPointer" declaration. If this is actually a pointer (address), it should be declared as "integer(int_ptr_kind()) iPointer" so that it will be correct on a 64-bit platform.

[van_der_merwe__ben]

Allrighteee!

With the same type of change made on the source files which gave this error, it compiles and links and executes fine, as far as I can tell.

We were using Intel 9.1 up to now with Visual Studio 2005 (but compiling using our own makefile system) and the annoying thing was that if you trap a Fortran runtime range (bounds) error, you would not get a meanigful stack (had to go to disassembly to jump to the right address adn then flip to source code). But with 10.0.027 that has been fixed! Yai!

[Steven_L_Intel1]

I always like to see a happy customer.