This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fortran include line fixes and -fdec-include support
- From: Fritz Reese <fritzoreese at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, fortran <fortran at gcc dot gnu dot org>, mark dot eggleston at codethink dot co dot uk, Jeff Law <law at redhat dot com>
- Date: Mon, 12 Nov 2018 18:24:24 -0500
- Subject: Re: [PATCH] Fortran include line fixes and -fdec-include support
- References: <20181112145116.GS11625@tucnak>
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