This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fortran include line fixes and -fdec-include support


On Mon, Nov 12, 2018 at 9:51 AM Jakub Jelinek <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]