Problem compiling old fortran code: error #8251:An input item must not appear as the implied-DO variable of any implied-DO loop that contains the input item

[Martin_Hall]

Hi there,

I'm using the evaluation version of Fortran compiler for MAC OS X versionVersion 12.0.0 and I come across the following error:

atlas9mem_newodf.for(4007): error #8251: An input item must not appear as the implied-DO variable of any implied-DO loop that contains the input item. [IZ] 1TRBPOW,TRBSND,TRBCON,XSCALE,(IZ,ABUND(IZ),IZ=1,99)

The piece of code in error is:

READ(3,1171) TEFF,GLOG,WLTE,TITLE,IFOP,A,MIXLTH,B,TRBFDG,

1TRBPOW,TRBSND,TRBCON,XSCALE,(IZ,ABUND(IZ),IZ=1,99)

1171 FORMAT(5HTEFF ,F7.0,9H GRAVITY,F8.5,1X,A4/6HTITLE ,74A1/

1 13H OPACITY IFOP,20I2/

2 12H CONVECTION ,A3,F6.2,12H TURBULENCE, A3,4F6.2/

3 16HABUNDANCE SCALE ,F9.5,17H ABUNDANCE CHANGE,2(I2,F8.5)/

4(17H ABUNDANCE CHANGE,6(I3,F7.2)))

READ(3,1171) TEFF,GLOG,WLTE,TITLE,IFOP,A,MIXLTH,B,TRBFDG, 1TRBPOW,TRBSND,TRBCON,XSCALE,(IZ,ABUND(IZ),IZ=1,99)1171 FORMAT(5HTEFF ,F7.0,9H GRAVITY,F8.5,1X,A4/6HTITLE ,74A1/ 1 13H OPACITY IFOP,20I2/ 2 12H CONVECTION ,A3,F6.2,12H TURBULENCE, A3,4F6.2/ 3 16HABUNDANCE SCALE ,F9.5,17H ABUNDANCE CHANGE,2(I2,F8.5)/ 4(17H ABUNDANCE CHANGE,6(I3,F7.2)))

The thing is, this same piece of code compiles fine with version Version 10.0 of ifort for linux running on a red-hat implementation. I'm merely re-compiling the original src code so I can port it from the Linux to the Mac , so I cant make any changes to the source code. I'm puzzled as to what has changed between the two versions to suddenly cause this restriction - any ideas ? Is there any other way I can port the code; I'm guessing it's not possible to compile on the Linux to run on a Mac ?

Cheers,

Martin

[mecej4]

This part of the I/O list does not make sense, and is not allowed by the Fortran standard:

READ(..,..)...,(IZ,ABUND(IZ),IZ=1,99)

The variable IZ is used as an input item and also as an implied DO loop index that controls the input of IZ. Plausible changes are:

(JFK, ABUND(IZ),IZ=1,99)

and

(IZ,ABUND(IZ)),JFK=1,99)

You must consider what the input data contains and what the code is trying to accomplish. The first choice that I gave ignores the input integers in the (INTEGER, REAL) data pairs, but assumes that the data are in sequential order. The second choice is more suitable if there are 99 pairs of data that are not in sequential order. If any index is repeated, a later READ replaces a value read earlier.

Compilers, especially Intel's, are getting better at spotting errors at compile time. Code that sneaked past the compiler in the past but now is flagged as being in error is code that needs to be repaired. In fact, you need to investigate why the code appeared to work correctly, whether it worked correctly, and how to achieve the desired effect with standard-conformant code.

[Kevin_D_Intel]

As mecej4 indicates, the 10.0 compiler did not detect this Fortran standard violation. It was detected and reported initially by the 11.1 release. The code will need to be corrected.

You are correct, the Linux compilers cannot be used to compile and target Mac OS X.

[Martin_Hall]

Mecej4, Keven - many thanks for your assistance. I have now modified the code as per the example, and it compiles fine,

Cheers,

Martin

[GSC-IAC]

Hi Martin,

I'm trying to compile the same code. Which one of the two options that mecej4 wrote was the right one?

Thanks.

[mecej4]

IFort 8.1, which the ATLAS pages names as the reference compiler, treats the offending line

READ(..,..)...,(IZ,ABUND(IZ),IZ=1,99)

as if it were written

READ(..,..)...,(IZ,ABUND(IZ)),JFK=1,99)

where JFK is used simply as a loop count index and is not used for anything else.

I drew this conclusion from a small test program, and it is quite possible that in different contexts and with different options (I used /Zi) the compiler could behave quite differently.

Whether that is the desired behavior or not is for the authors of the code and you, the users of the software and data files, to enquire into and, please, do fix the read statement once and for all. Because of this bug, the usual dire cautionary statements can be made about using the questionable program results in ways that affect lives.