Fortran line lengths

[Nicolas König]

Hello Thomas,

I don't think that there is a good reason for the 132-Character limit,
and as far as I know, the standard committee are trying to get rid of it
in Fortran2X.

I wouldn't be opposed to anticipating the committees decision
allowing longer lines as a gnu language extension until it is
standardized.

Kind regards

   Nicolas König


On 14/10/2020 09:42, Thomas Schwinge wrote:
> Hi Fortran!
> 
> Moving this general discussion over from <https://gcc.gnu.org/PR97390>.
> 
> There is source code similar to:
> 
>      !$acc data present(tempRbuffer, array, compactHaloInfo, dimsizes, nHaloLayers, gpu_nList_send, gpu_idx_send, gpu_bufferOffset_send) async(counter+1)
> 
> ..., that is, a free-form Fortran line longer than 132 characters.  It's
> an OpenACC directive masqueraded as a Fortran comment, but my question
> likewise applies to actual Fortran code.  I'm not talking about coding
> style (I'd certainly break up such a thing to use continuation lines for
> each clause, for example).  By default, we refuse that long line with
> "Error: Syntax error in OpenMP variable list".
> 
> On 2020-10-13T17:33:14+0000, "burnus at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> wrote:
>> --- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
>> (In reply to Thomas Schwinge from comment #1)
>>> Would it be the case that this line is longer than 132 characters?  [...]
>>> (I cannot comment on (a) why that's a useful limit to have
>>
>> I don't know whether it is useful or not
> 
> I'm not a language lawyer, obviously, and have not read the Fortran
> standard, so it'll be easy to "shoot me down" if so desired.  ;-P
> 
> I don't think this compile-time error is useful.  There is no actual
> "Syntax error in [...] variable list", it's just that the line is "too
> long" (and presumably cut off after 132 characters, thus the compiler
> introducing/Fortran standard mandating said syntax error).
> 
>> but the Fortran standard has:
>>
>> "In free source form [...] If a line consists entirely of characters of default
>> kind (7.4.4), it shall contain at most 132 characters" (Fortran 2018, 6.3.2.1
>> Free form line length)
> 
> I'm curious, what is the rationale (nowadays)?  Free-form Fortran code
> doesn't have to fit onto fixed-size punchcards anymore, after all.  I can
> understand if specifications have a comment such that "some limit (no
> lower than [...]) may be imposed by the implementation" (similar to
> <https://stackoverflow.com/questions/11614687/maximum-length-of-statement-in-c>,
> etc. -- but note: "implementations should avoid imposing fixed
> translation limits whenever possible").  But isn't this 132 characters
> limit overly restrictive?  We're again and again seeing user reports
> running into this, and the "solution" is '-ffree-line-length-none'.
> 
> Does the Fortran standard really mandate a compile-time error, or could
> we at least demote this to a warning (with '-pedantic' only, even?)?
> 
> 
> Grüße
>   Thomas
> 
> 
> P.S.:
> 
>>> , and (b) whether the error reporting shouldn't be improved.)
> 
>> [...] my error message improvements for GCC 10 really help. With
>> -ffree-line-length-none, the error is:
>>
>> With GCC 9's : Error: Unclassifiable OpenACC directive at (1)
>>
>> With GCC 10 or GCC 11:
>>
>>      2 |            !$acc data present(tempRbuffer, array, compactHaloInfo, dimsizes, nHaloLayers, gpu_nList_send, gpu_idx_send, gpu_bufferOffset_send) async(counter+1)
>>        |                                                                                                                                                1
>> Error: Failed to match clause at (1)
>>
>> Note the '1' is at 'async(...)'
> 
> Yes, that's much more useful, indeed!
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
>