Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Beginner
73 Views

Fortran 77/ Fortran 90 Compatibility for Intel Fortran 11.1.046

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
73 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
Beginner
73 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
Black Belt
73 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
New Contributor I
73 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
Beginner
73 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
Black Belt
73 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
Beginner
73 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
Employee
73 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
New Contributor I
73 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
73 Views

Yes, it appears that this fix will make it in to Update 3.
0 Kudos
73 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