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

Fortran 77/ Fortran 90 Compatibility for Intel Fortran 11.1.046

Derek_Brown
Beginner
958 Views
When I upgraded from Intel Fortran 11.1.038 to 046 my application stopped compiling due to the new CLASS keyword:

- making xxxx.o from xxxx.f
ifort -nologo -names:lowercase -assume:underscore -assume:no2underscore -threads -libs:dll -Qdiag-disable:remark -O3 -Zi -c xxxx.f -object:xxxx.o
xxxx.f(62): error #5082: Syntax error, found IDENTIFIER 'POP' when expecting one of: ( % : . = =>
classpop(j, 1) = tclasspop(j)
--------------^

Changing this code presents difficulties, and hence I'd like to use a compatibility option to read Fortran 90 or Fortran 77 syntax. I have been unable to identify that option. Does that option exist? If so what is its name?

I am working with Intel Fortran 11.1.046 on Windows 2003 Server, VIsual Studio 2008 installed, but using make to run this particular build.

Thanks in advance,
Derek . . .


0 Kudos
11 Replies
Steven_L_Intel1
Employee
958 Views
This is simply a compiler bug - it has nothing to do with Fortran 77 or Fortran 90. However, I can't reproduce this error in 11.1.046 - can you provide a short but complete program that demonstrates the error? A related bug was fixed in 11.1.046.
0 Kudos
Derek_Brown
Beginner
958 Views

The following shows how I set the path, the four line source file, the ifort call, and its output. The source file is not a complete program: It is just the source for a subroutine, but does show the compiler error. It compiles cleanly if you change all occurances of classpop to aclasspop. Thanks for the prompt reply!!
Derek . . .

C:DerekWorkspacefortranError>set Path=C:Program Files (x86)IntelCompiler11.1�46\binia32;C:Program Files (x86)IntelCompiler11.1�46tbbintel64vc9bin;C:Program Files (x86)IntelCompiler11.1�46ippem64tbin;C:Program Files (x86)IntelCompiler11.1�46mklem64tbin;C:Program Files (x86)Windows Resource KitsTools;C:ProgramsMiKTeX2.7miktexbin;C:Program Files (x86)IntelCompiler11.1�46libIntel64;C:Program Files (x86)IntelCompiler11.1�46libia32;C:Program Files (x86)IntelCompiler11.1�46libIntel64;C:Program Files (x86)IntelCompiler11.1�46libia32;C:Program Files (x86)CollabNet Subversion Client;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;c:Program Files (x86)Microsoft SQL Server90Toolsbinn;C:Program FilesTortoiseSVNbin;C:WINDOWSsystem32WindowsPowerShellv1.0

C:DerekWorkspacefortranError>type xxxx.f

subroutine buildtree(classpop, tclasspop, nrnodes, nclass)

implicit double precision(a-h,o-z)

double precision tclasspop(nclass), classpop(nclass, nrnodes)

classpop(j, 1) = tclasspop(j)

end


C:DerekWorkspacefortranError>ifort -c xxxx.f -object:xxxx.o
Intel Visual Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 20090903 Package ID: w_cprof_p_11.1.046
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

xxxx.f(7): error #5082: Syntax error, found IDENTIFIER 'POP' when expecting one of: ( % : . = =>
classpop(j, 1) = tclasspop(j)
-----------^
xxxx.f(7): error #6535: This variable or component must be of a derived or structure type [CLASS]
classpop(j, 1) = tclasspop(j)
------^
xxxx.f(7): error #6460: This is not a field name that is defined in the encompassing structure. [POP]
classpop(j, 1) = tclasspop(j)
-----------^
compilation aborted for xxxx.f (code 1)

0 Kudos
TimP
Honored Contributor III
958 Views
I have to change it to fixed form (with leading spaces) in order to get anything resembling the problem you show. But it's not valid Fortran even under f77, with the undefined/unitialized variable j (and, to be pedantic, lower case and variable names longer than 6 characters). It does look like the compiler is no longer working in fixed source format.
0 Kudos
abhimodak
New Contributor I
958 Views
Looks like the usage of "class" is causing the problem ...I think, for now, changing the file extension to .f90 or making it free form would work.

Abhi
0 Kudos
kaveiros
Beginner
958 Views
Excuse me if I am at the wrong forum.

I have a question about fortran77.

I have a program written in a later version of fortran (don't know which one). I want to compile this program with f77 but obviously the RECORDTYPE='stream' is causing me problems. Is there any equivalent to RECORDTYPE in fortran77? For example should I replace it with ACCES or RECL, or both?


Thanks in advance.

K.
0 Kudos
TimP
Honored Contributor III
958 Views
Quoting - kaveiros

I have a question about fortran77.

I have a program written in a later version of fortran (don't know which one). I want to compile this program with f77 but obviously the RECORDTYPE='stream' is causing me problems. Is there any equivalent to RECORDTYPE in fortran77? For example should I replace it with ACCES or RECL, or both?

Fortran 77 didn't have a standard method to specify this. It might have been done in JCL, or there might have been just one or 2 of the RECORDTYPE options available, depending on OS. You would have to consult the documentation of the specific compiler you are using; if undocumented, there may be no equivalent control.
0 Kudos
Derek_Brown
Beginner
958 Views
Quoting - abhimodak
Looks like the usage of "class" is causing the problem ...I think, for now, changing the file extension to .f90 or making it free form would work.

Abhi

Yep, as workaround we did was changing the code: changing the name from classpop to aclasspop.
Derek . . .
0 Kudos
Lorri_M_Intel
Employee
958 Views

I've submitted this into our internal problem tracking tool asid DPD200140131

I'm glad to hear you have a workaround until we can resolve it.

- Lorri
0 Kudos
abhimodak
New Contributor I
958 Views
Hi

I am wondering if the fix will be available in update 3 of scheduled for late October. This is sort of critical to successfully build a program with a lot of files that uses variables with names *class*. (Unfortuantely these are fixed format files). Changing the variable names or file extensions is not an attractive option.

Since this bug infringes upon (:)) a very basic freedom (use of variable name), I am hoping that it is a high priority issue.

Abhi
0 Kudos
Steven_L_Intel1
Employee
958 Views
Yes, it appears that this fix will make it in to Update 3.
0 Kudos
Steven_L_Intel1
Employee
958 Views
Fixed in 11.1 Update 3, though it's missing from the list of fixes for that update due to an oversight.
0 Kudos
Reply