Re: Problem with for_isodef.for in 11.1.046

dannycat · ‎09-20-2009

Since upgading to 11.1.046 I am getting undefined variable errors when attempting to compile a f90 source that includes the file for_isodef.for file.None ofthe parameters defined have a type, so it looks like the latest compiler is picking up on this.

Example:

PARAMETER FOR$IOS_PERACCFIL = '00000009'X

Should this be:

INTEGER,PARAMETER :: FOR$IOS_PERACCFIL = '0000000009'X

What's the best work-round. I could define the parameters I need explicitly.

Steven_L_Intel1 · ‎09-20-2009

The syntax is correct - this is a feature that almost but not quite made it into F77, but we had already implemented itl. The type is taken from the constant.

Steven_L_Intel1 · ‎09-21-2009

I had written earlier (in a post I since deleted) that I could reproduce this, but it turns out I made an error. Would you please show a small source that shows this problem and also show the error message?

dannycat · ‎09-21-2009

Quoting - Steve Lionel (Intel)

I had written earlier (in a post I since deleted) that I could reproduce this, but it turns out I made an error. Would you please show a small source that shows this problem and also show the error message?

Steve

Something very strange seems to be happening here! In order to simplify the example I copied the file in question to a new version with the intention of removing code until I had a small file to send. I did this with my main solution and inserted the file into (what I thought of was) the same project so that I could keep recompiling to check that I was getting the same error messages. Guess what? Compilation worked! I'd mistakenly insert the file into a different project within the solution.

These are the messages I get with original file.

1>C:WinFEM2000Generalnp_savemodel.f90(574): error #6404: This name does not have a type, and must have an explicit type. [FOR$IOS_BUG_CHECK]
1>C:WinFEM2000Generalnp_savemodel.f90(578): error #6404: This name does not have a type, and must have an explicit type. [FOR$IOS_PERACCFIL]

Why should this depend upon what project the file is contained in? I can't see any obvious settings that would cause this, but perhaps you could suggest something.

Steven_L_Intel1 · ‎09-21-2009

Do you perhaps have a rogue copy of for_iosdef.for in among your source files?

dannycat · ‎09-22-2009

Quoting - Steve Lionel (Intel)

Do you perhaps have a rogue copy of for_iosdef.for in among your source files?

Steve
As a matter of fact I do have a copy of the file in the solution directory (so that theCVF versionof my project will pick it up). I tried removing this filebut the problem doesn't go away.

There is a shortcut in the users C:UserssteveAppDataRoamingMicrosoftWindows|for_iosdef.for which points to
C:Program FilesIntelCompiler11.1�46includefor_iosdef.for

Steven_L_Intel1 · ‎09-22-2009

Try renaming (temporarily) the one in the compiler's INCLUDE folder, so that, theoretically, it won't be found, and see what happens.

dannycat · ‎09-22-2009

Quoting - Steve Lionel (Intel)

Try renaming (temporarily) the one in the compiler's INCLUDE folder, so that, theoretically, it won't be found, and see what happens.

It can't find the file 'error #5102: Cannot open include file 'for_iosdef.for''. (Also get the "name does not have type" errors #6404).

Is there a way to create a listing of the source with includes incorporated?

Renamed it back and I get the original errors (#6404) only.

Steven_L_Intel1 · ‎09-22-2009

At the moment, we don't support a source listing. That will come in the future. It's interesting that you can't reproduce this in a separate test case. Can you copy the existing project folder and see it there? Please attach the buildlog.htm from a failed build.

dannycat · ‎09-22-2009

Quoting - Steve Lionel (Intel)

At the moment, we don't support a source listing. That will come in the future. It's interesting that you can't reproduce this in a separate test case. Can you copy the existing project folder and see it there? Please attach the buildlog.htm from a failed build.

Steve here are contents of build log (Debug configuration).

Compiling with Intel Visual Fortran 11.1.046 [IA-32]...
ifort /nologo /debug:full /Od /I"..Resource/" /I"C:Winf90gllibIVF32/" /I"C:Winf90SQLIVF32/" /I"..ModulesDebug/" /I"..NASTRANDebug/" /I"..AnalysisDebug/" /DCONFIG=WIN32 /warn:unused /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c /Qvc9 /Qlocation,link,"c:Program Files (x86)Microsoft Visual Studio 9.0VCbin" "C:WinFEM2000Generalnp_savemodel.f90"
C:WinFEM2000Generalnp_savemodel.f90(574): error #6404: This name does not have a type, and must have an explicit type.   [FOR$IOS_BUG_CHECK]
if(ier.eq.FOR$IOS_BUG_CHECK) then
----------^
C:WinFEM2000Generalnp_savemodel.f90(578): error #6404: This name does not have a type, and must have an explicit type.   [FOR$IOS_PERACCFIL]
else if(ier.eq.FOR$IOS_PERACCFIL) then
---------------^
compilation aborted for C:WinFEM2000Generalnp_savemodel.f90 (code 1)

General - 3 error(s), 0 warning(s)



I have just tried switching from Debug to Release the problem goes away! Does this give you any clues?
Here's the build log for successful compilation.



Compiling with Intel Visual Fortran 11.1.046 [IA-32]...
ifort /nologo /I"..Resource/" /I"..ModulesRelease/" /I"..AnalysisRelease/" /I"..NASTRANRelease/" /I&quotC:Winf90gllibIVF32/" /I&quotC:Winf90SQLIVF32/" /DCONFIG=WIN32 /warn:noalignments /module:&quotRelease/" /object:&quotRelease/" /traceback /libs:static /threads /c /Qvc9 /Qlocation,link,&quotc:Program Files (x86)Microsoft Visual Studio 9.0VCbin" &quotC:WinFEM2000Generalnp_savemodel.f90"

General - 0 error(s), 0 warning(s)

Steven_L_Intel1 · ‎09-22-2009

In the Debug configuration, do a Build > Clean and then rebuild. Does the error still occur?

dannycat · ‎09-23-2009

Quoting - Steve Lionel (Intel)

In the Debug configuration, do a Build > Clean and then rebuild. Does the error still occur?

Steve,

I already tried this before submitting the first post. Needless to say it didn't solve the problem.

Summarising:

1) Built OK in previous version of compiler 11.1.038, both debug and release IA-32 & x64
2) Builds in 11.1.046 Release config IA-32 & x64
3) Fails in 11.1.046 Debug config in current project IA-32 & x64
4) Builds in 11.1.046 Debug in different project with same solution as 3) above. IA-32 & x64.

How does the compiler obtain the data type of the FOR$*** parameters?

Steven_L_Intel1 · ‎09-23-2009

It derives the type from the form of the constant. This is different from the standard form of PARAMETER with parentheses in which normal implicit typing rules apply.

If you make a copy of the entire solution folder and open the copy, does it still fail? If so, would you be willing to ZIP that and provide it to us? You can attach it here or submit it to Intel Premier Support.

dannycat · ‎09-23-2009

Quoting - Steve Lionel (Intel)

It derives the type from the form of the constant. This is different from the standard form of PARAMETER with parentheses in which normal implicit typing rules apply.

If you make a copy of the entire solution folder and open the copy, does it still fail? If so, would you be willing to ZIP that and provide it to us? You can attach it here or submit it to Intel Premier Support.

Steve

I will try to provide you with something but it may take me a while to sort it out.

I had a look at the for_iosdef.for file and it looks toas thoughthe FOR_IOSDEF definition is already set causing the compiler to disregard the parameter definitions.

If I add the line

!DEC$ UNDEFINE FOR_IOSDEF

before the include 'for_iosdef.for' statement I get the warning:

#5168: Undefined conditional compilation variable

but the source compiles OK. (??? very confused!)

Where else could this definition be set?

Is the problem related to the compiler directives somewhere?

Steven_L_Intel1 · ‎09-23-2009

That symbol would be set only if the file had already been included. I don't think that's relevant.