On Mon, Nov 12, 2018 at 9:51 AM Jakub Jelinek <ja...@redhat.com> wrote: > > In fortran97.pdf I read: > "Except in a character context, blanks are insignificant and may be used > freely throughout the program." > and while we handle that in most cases, we don't allow spaces in INCLUDE > lines in fixed form, while e.g. ifort does.
I agree with fixing this unconditionally. > Another thing, which I haven't touched in the PR except covering it with a > testcase is that we allow INLINE line in fixed form to start even in columns > 1 to 6, while ifort rejects that. Is say > include 'omp_lib.h' > valid in fixed form? i in column 6 normally means a continuation line, > though not sure if anything can in a valid program contain nclude > followed by character literal. Shall we reject that, or at least warn that > it won't be portable? AFAICT this is unambiguous so I would certainly suggest adding such a warning (enabled by default). > The last thing, biggest part of the patch, is that for legacy DEC > compatibility, the DEC manuals document INCLUDE as a statement, not a line, > [...] > This means there can be (as can be seen in the following testcases) > continuations in both forms, and in fixed form there can be 0 in column 6. Makes sense to me. I concur with adding -fdec-include to support this under -fdec. If we are going to warn for the above and re-do the include matching anyway, I wonder if we should have also a specific error message for a labeled include statement? For example, 10 include 'include_10.inc' Will result in the generic 'Unclassifiable statement' error, but ifort gives "Label on INCLUDE is invalid." > In order not to duplicate all the handling of continuations, comment > skipping etc., the patch just adjusts the include_line routine so that it > signals if the current line is a possible start of a valid INCLUDE statement > when in -fdec-include mode, and if so, whenever it reads a further line it > retries to parse it using > gfc_next_char/gfc_next_char_literal/gfc_gobble_whitespace APIs as an INCLUDE > stmt. If it is found not to be a valid INCLUDE statement line or set of > lines, it returns 0, if it is valid, it returns 1 together with load_file > like include_line does and clears all the lines containint the INCLUDE > statement. If the reading stops because we don't have enough lines, -1 is > returned and the caller tries again with more lines. LGTM. > In addition to the above mentioned question about include in columns 1-6 in > fixed form, another thing is that we support > print *, 'abc''def' > print *, "hij""klm" > which prints abc'def and hij"klm. Shall we support that for INCLUDE lines > and INCLUDE statements too? It appears ifort does also support this. I see no reason not to, as the feature should be straightforward to implement. > Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest? With the above additions it looks ok to me, but I must defer to an official Fortran reviewer. --- Fritz
