line length check

line length check

Ritratto di Andrew May
Andrew May
Ven, 19/08/2011 - 00:45

When using '-stand 03' option to ifort I'm getting warnings about the line length, even though they are below the 132 allowed by the standard. In all cases it involves a variable name being split across 2 lines. Here are the 2 lines of code in question:

 res(21)=5.d-1*t134375*(1.5d0*t134375*t134382+5.d-1*t134375*(-(t134374*t134375*t134380)+5.d-1*t134375*(t134444+5.d-1*t134374*t13& &4375*t134445)))
and here is the resulting warning when compiling with '-stand 03':

basis_shell_pg_kpoint.F90(189): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line. res(21)=5.d-1*t134375*(1.5d0*t134375*t134382+5.d-1*t134375*(-(t134374*t134375*t134380)+5.d-1*t134375*(t134444+5.d-1*t134374*t134375& ------------------------------------------------------------------------------------------------------------------------------------^

So it appears the compiler has moved the line ending onto the next line and is counting the line plus the remainder of the variable name on the next line when calculating the line length. Is this correct? Surely the line length check should not 'extend' onto the next line?

This is seen with:

Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.2.137 Build 20110112 Copyright (C) 1985-2011 Intel Corporation. All rights reserved
Any ideas what the problem is?

Many thanks

Andy

RSS In cima
8 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Ven, 19/08/2011 - 02:15

The fpp preprocessor is implicitly called with the .F90 file extension and preprocessing re-constructs the first line without the split variable name. The resulting first line then becomes 132 characters, so the front-end sees this:

res(21)=5.d-1*t134375*(1.5d0*t134375*t134382+5.d-1*t134375*(-(t134374*t134375*t134380)+5.d-1*t134375*(t134444+5.d-1*t134374*t134375&
&*t134445)))

When the variable name is rejoined and the original source line begins in column 2 or greater, the line then exceeds the 132 character length and that triggers the warning. The error does not occur when the original line begins in column 1.

The warning is also avoidable using the .f90 extension or not splitting the variable name across two lines as so:

res(21)=5.d-1*t134375*(1.5d0*t134375*t134382+5.d-1*t134375*(-(t134374*t134375*t134380)+5.d-1*t134375*(t134444+5.d-1*t134374*&
&t134375*t134445)))

Unclear whether this would be considered a defect or not or whether this may have been reported before. I will report this to the Developers and note the internal tracking id below.

(Internal tracking id: DPD200172620)

(Resolution Update on 10/14/2012): This defect is fixed in the Intel® Fortran Composer XE 2013 Initial Release (2013.0.0.079 - Linux)

In cima
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Ven, 19/08/2011 - 04:43

Correction. Not splitting the variable name across lines may notavoid the warning. Not splitting the name and placing it completely on the continued line as I showed just allows for more leading white space on the firstline. The warning still appearswhere sufficient leading white space pushes the first line length beyond 132 characters.

So, the preprocessor rewrites lines 132 characters in length but without regard to leading white space, thus the line exceeds the Standard and triggers the warning. That is a defect in the preprocessing in my view.

In cima
Ritratto di Andrew May
Andrew May
Ven, 19/08/2011 - 04:50

Kevin,

Sure, we have some '#ifdef' etc. in our files so we use .F90 suffix to envoke the preprocessor.

Thanks for the explanation, I now understand what's happening. I'm not sure the preprocessor should get involved in this case; it's plain Fortran which should be invariant under the action of the preprocessor.

At present the behaviour of ifort differs from all other compilers, eg.:

ifort -E test.F90 > ifort.F90

does not agreee with:

gfortran -E test.F90 > gfortran.F90
openf90 -E test.F90 > openf90.F90
cp test.F90 sunf90.F90; sunf90 -F sunf90.F90

which all do not rejoin the line.

In cima
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Ven, 19/08/2011 - 05:15

Agreed. The preprocessor should read/re-write these linesas is. I'll update the thread with status on a fix as I learn it.

In cima
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Ven, 19/08/2011 - 06:31

If these become a major nuisancethe best work around is to silence them by adding the option: -diag-disable 5268

In cima
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Gio, 25/08/2011 - 01:45

Development found the root cause. A fix will be available in a future release wherepreprocessig will no longer join two parts of a token separated by the & unless it appears within a macro definition where joining is required.

I will update this thread when a fix is available.

In cima
Ritratto di Kevin Davis (Intel)
Kevin Davis (Intel)
Dom, 14/10/2012 - 01:01

The defect with the preprocessor reported in this thread is fixed in our current Intel® Fortran Composer XE 2013 Initial Release (2013.0.0.079 - Linux).

In cima

Accedere per lasciare un commento.