[Patch, Fortran] PR64522 - reinstate truncation diagnostic

[Tobias Burnus]

Thomas Koenig wrote:
> Am 08.01.2015 um 16:10 schrieb Tobias Burnus:
>> For free-form source code, that's very uncommon - especially as several
>> compilers do not honour the line limit of 132 characters (with default
>> settings). [...]
>> I think think it makes sense to have some diagnostic in this case. Either
>> by re-instating the warning or even by printing an error.
> [...]
>> This patch does the latter by using the warning infrastructure.
> is not correct.  We should not emit an error by default for valid, if
> unusual, Fortran code.

Well, according to the Fortran standard, only 132 (default-kind) 
characters are valid in free-form source code:

"13.3.2.1 Free form line length
"In free source form there are no restrictions on where a statement (or 
portion of a statement) may appear within a line. A line may contain 
zero characters. If a line consists entirely of characters of default 
kind (4.4.3), it may contain at most 132 characters. If a line contains 
any character that is not of default kind, the maximum number
of characters allowed on the line is processor dependent." (From the 
current F2015 early draft.)

The Fortran standard does not specify what happens if a program exceeds 
this limit. Thus, such a program is not standard conform and compilers 
can do what they like. Namely:

a) aborting the compilation with an error
b) truncating at the line-length limit
c) continue reading even beyond 132 characters

As written, for fixed-form source code, (b) seems to be the common 
solution with all compilers for historic reasons. (Also because a "!" to 
start a comment mid-line didn't exist until Fortran 90.)

For free-form source code, (c) seems to rather common (gfortran's 
-ffree-line-length-none); that's done by Cray ftn, PGI and ifort. I am 
pretty sure that pathf95 does likewise [=(c)] and that NAG f95 prints an 
error [= (a)] but I cannot test neither at the moment - nor other 
compilers like g95. I think Absoft, Oracle's OSS, Crayftn and Pathf95 
are based on the SGI Fortran front end (all heavily modified); thus, I'd 
expect that all do likewise [=(c)].

Therefore, (b) seems to be odd as (most? all?) other compilers do not 
truncate and as it may yield wrong results in corner cases - like in my 
"print *, 15" (many spaces) "+ 5" example, where it gives with gfortran 
15 and with the compilers listed under (c) it shows 20. [Something like 
that might easily happen unnoticed, e.g. the trunctation of trailing 
digits in an integer or floating point number "* 1000.0" might become "* 
1".]

As compilers like (c) exists, I doubt any free-form program puts a 
comment after column 132 without using a "!" - especially as it is 
easily fixable by adding a "!".

Thus, I still believe the most sensible is to error out. If someone 
really wants to use truncation, they still can silence the error using 
-Wno-line-truncation (or -Wno-error, if they still want to have the 
warning). The name of the warning flag, is even shown in the diagnostic! 
But I regard is as highly unlikely that a user will use 
-Wno-line-truncation. (Or, if they do, they probably intent 
-ffree-line-length-none instead and not truncation.)

Based on the latter, one could actually consider to add a reference to 
"-ffree-line-length-none" in the message. Either in the message or as 
"Note:" (inform(), DK_NOTE) [not yet used in gfortran].

> My suggestion would be to turn this into a warning, which can be
> suppressed if necessary.

As can be the error – at least in the way I implemented it in the patch.

Tobias