[Patch, Fortran] PR64522 - reinstate truncation diagnostic

[Janne Blomqvist]

On Thu, Jan 8, 2015 at 9:18 PM, Tobias Burnus <burnus@net-b.de> wrote:
> 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.

To be honest, I can't really see a sensible reason for ever wanting
the truncation behavior for free form. Particularly not silently
truncating! So as an alternative, consider:

- Get rid of the -ffree-line-length-* options (perhaps silently
accepting them to avoid breaking existing makefiles), always behave as
if -ffree-line-length-none is in effect.

- Emit a warning if a line exceeds 132 characters (which would then
become an error with -Werror, -pedantic or such options)


That being said, it seems that silently truncating is the expected
behavior for fixed form, even though the description of the 72
character limit is similar to that for free form (F2008 3.3.3.1).
Consider F2008 (N1830) note 3.10 (page 48) which describes include
files which can be used both as free and fixed form:

" For continued statements, place an ampersand (&) in both character
position 73 of a continued line and character
position 6 of a continuation line."

which implies that a compiler processing fixed-form source should
silently ignore whatever is beyond character position 72. So for
symmetry reasons one could argue that silently truncating is also the
correct approach for free form.. :-/


-- 
Janne Blomqvist