From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Harald Anlauf <anlauf@gmx.de>
Cc: Jerry D <jvdelisle2@gmail.com>, gfortran <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
Date: Sun, 7 May 2023 17:13:40 -0700 [thread overview]
Message-ID: <ZFg+tMT3WlFWNNpK@troutmask.apl.washington.edu> (raw)
In-Reply-To: <658d646d-d699-0d7c-06ce-396af393008f@gmx.de>
Harald,
Thanks for keeping us honest. I didn't check what other
separators might cause a problem.
After 2 decades of working on gfortran, I've come to conclusion
that -std=f2018 should be the default. When f2023 is ratified,
the default becomes -std=f2023. All GNU fortran extension
should be behind an option, and we should be aggressive
eliminating extensions.
Yes, this means that 'real*4' and similar would require
a -fallow-nonstandard-declaration option.
--
steve
On Sun, May 07, 2023 at 08:33:43PM +0200, Harald Anlauf wrote:
> Hi Jerry,
>
> I've made a small compiler survey how they behave on namelist read
> from an internal unit when:
>
> 1.) there is a single input line of the type
> "&stuff" // testchar // " n = 666/"
>
> 2.) the input spans 2 lines split after the testchar
>
> 3.) same as 2.) but first line right-adjusted
>
> See attached source code.
>
> Competitors: Intel, NAG, NVidia, gfortran at r14-547 with -std=f2018.
>
> My findings were (last column is iostat, next-to-last is n read or -1):
>
> NAG:
>
> Compiler version = NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
> 1-line: > < 666 0
> 2-line/left: > < 666 0
> 2-line/right: > < 666 0
> 1-line: >!< -1 187
> 2-line/left: >!< -1 187
> 2-line/right: >!< -1 187
> 1-line: >/< -1 187
> 2-line/left: >/< -1 187
> 2-line/right: >/< -1 187
> 1-line: >,< -1 187
> 2-line/left: >,< -1 187
> 2-line/right: >,< -1 187
> 1-line: >;< -1 187
> 2-line/left: >;< -1 187
> 2-line/right: >;< -1 187
> 1-line: tab 666 0
> 2-line/left: tab 666 0
> 2-line/right: tab 666 0
> 1-line: lf -1 187
> 2-line/left: lf -1 187
> 2-line/right: lf -1 187
> 1-line: ret -1 187
> 2-line/left: ret -1 187
> 2-line/right: ret -1 187
>
> My interpretation of this is that NAG treats tab as (white)space,
> everything else gives an error. This is the strictest compiler.
>
> Intel:
>
> Compiler version = Intel(R) Fortran Intel(R) 64 Compiler Classic for
> applications running on Intel(R) 64, Version 2021.9.0 Build 20230302_000000
> 1-line: > < 666 0
> 2-line/left: > < 666 0
> 2-line/right: > < 666 0
> 1-line: >!< -1 -1
> 2-line/left: >!< 666 0
> 2-line/right: >!< 666 0
> 1-line: >/< -1 0
> 2-line/left: >/< -1 0
> 2-line/right: >/< -1 0
> 1-line: >,< -1 17
> 2-line/left: >,< -1 17
> 2-line/right: >,< -1 17
> 1-line: >;< -1 17
> 2-line/left: >;< -1 17
> 2-line/right: >;< -1 17
> 1-line: tab 666 0
> 2-line/left: tab 666 0
> 2-line/right: tab 666 0
> 1-line: lf 666 0
> 2-line/left: lf 666 0
> 2-line/right: lf 666 0
> 1-line: ret -1 17
> 2-line/left: ret -1 17
> 2-line/right: ret -1 17
>
> Nvidia:
>
> Compiler version = nvfortran 23.3-0
> 1-line: > < 666 0
> 2-line/left: > < 666 0
> 2-line/right: > < 666 0
> 1-line: >!< -1 -1
> 2-line/left: >!< -1 -1
> 2-line/right: >!< -1 -1
> 1-line: >/< -1 -1
> 2-line/left: >/< -1 -1
> 2-line/right: >/< -1 -1
> 1-line: >,< -1 -1
> 2-line/left: >,< -1 -1
> 2-line/right: >,< -1 -1
> 1-line: >;< -1 -1
> 2-line/left: >;< -1 -1
> 2-line/right: >;< -1 -1
> 1-line: tab 666 0
> 2-line/left: tab 666 0
> 2-line/right: tab 666 0
> 1-line: lf -1 -1
> 2-line/left: lf 666 0
> 2-line/right: lf 666 0
> 1-line: ret 666 0
> 2-line/left: ret 666 0
> 2-line/right: ret 666 0
>
> gfortran (see above):
>
> Compiler version = GCC version 14.0.0 20230506 (experimental)
> 1-line: > < 666 0
> 2-line/left: > < 666 0
> 2-line/right: > < 666 0
> 1-line: >!< -1 -1
> 2-line/left: >!< -1 0
> 2-line/right: >!< 666 0
> 1-line: >/< -1 0
> 2-line/left: >/< -1 0
> 2-line/right: >/< -1 0
> 1-line: >,< 666 5010
> 2-line/left: >,< 666 5010
> 2-line/right: >,< 666 5010
> 1-line: >;< 666 0
> 2-line/left: >;< 666 0
> 2-line/right: >;< 666 0
> 1-line: tab 666 0
> 2-line/left: tab 666 0
> 2-line/right: tab 666 0
> 1-line: lf 666 0
> 2-line/left: lf 666 0
> 2-line/right: lf 666 0
> 1-line: ret 666 0
> 2-line/left: ret 666 0
> 2-line/right: ret 666 0
>
>
> So there seems to be a consensus that "," and ";" must be rejected,
> and tab is accepted (makes real sense), but already the termination
> character "/" and comment character "!" are treated differently.
> And how do we want to treat lf and ret in internal files with
> -std=f20xx?
>
> Cheers,
> Harald
>
>
> On 5/7/23 19:33, Jerry D via Gcc-patches wrote:
> > On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote:
> > > Hi Jerry, Steve,
> > >
> > > I think I have to pour a little water into the wine.
> > >
> > > The patch fixes the reported issue only for a comma after
> > > the namelist name, but we still accept a few other illegal
> > > characters, e.g. ';', because:
> > >
> > > #define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
> > > || c == '\t' || c == '\r' || c == ';' || \
> > > (dtp->u.p.namelist_mode && c == '!'))
> > >
> > > We don't want that in standard conformance mode, or do we?
> > >
> > > Cheers,
> > > Harald
> > >
> > > On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote:
> > > > On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote:
> > > > > The attached patch adds a check for the invalid comma and emits a
> > > > > runtime
> > > > > error if -std=f95,f2003,f2018 are specified at compile time.
> > > > >
> > > > > Attached patch includes a new test case.
> > > > >
> > > > > Regression tested on x86_64-linux-gnu.
> > > > >
> > > > > OK for mainline?
> > > > >
> > > >
> > > > Yes. Thanks for the fix. It's been a long time since
> > > > I looked at libgfortran code and couldn't quite determine
> > > > where to start to fix this.
> > > >
> > >
> >
> > As I think back, I don't recall ever seeing a semi-colon used after a
> > NAMELIST name, so I think we should reject it always. The other "soft"
> > blanks we should allow.
> >
> > I will make a another patch on trunk to reject the semi-colon and if no
> > one objects here I will test and push it.
> >
> > Regards,
> >
> > Jerry
> >
> >
> program testnmlread
> use iso_fortran_env, only: compiler_version
> implicit none
> print *,'Compiler version = ',trim(compiler_version())
> call test (" ")
> call test ("!")
> call test ("/")
> call test (",")
> call test (";")
> call test (achar(9), "tab")
> call test (achar(10), "lf")
> call test (achar(13), "ret")
> contains
> subroutine test (c, desc)
> character, intent(in) :: c
> character(*), intent(in), optional :: desc
> character(8) :: d
> character(16) :: line, lines(2)
> integer :: ios
> integer :: n
> namelist/stuff/n
> character(*), parameter :: s1 = "&stuff", s2 = " n = 666/"
>
> d = ">" // c // "<"; if (present (desc)) d = desc
> ! Prepare input:
> line = s1 // c // s2
> lines(1) = s1 // c ! Left-adjusted
> lines(2) = s2
> ! Single line input
> n = -1
> read(line,nml=stuff,iostat=ios)
> write(*,*) "1-line: ", trim (d), n, ios
> ! Multi-line input
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/left: ", trim (d), n, ios
> lines(1) = adjustr (lines(1)) ! Right-adjust first line
> n = -1
> read(lines,nml=stuff, iostat=ios)
> write(*,*) "2-line/right: ", trim (d), n, ios
> end subroutine test
> end program testnmlread
--
Steve
next prev parent reply other threads:[~2023-05-08 0:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 3:41 Jerry D
2023-05-06 4:02 ` Steve Kargl
2023-05-06 18:15 ` Harald Anlauf
2023-05-06 18:15 ` Harald Anlauf
2023-05-07 17:33 ` Jerry D
2023-05-07 18:33 ` Harald Anlauf
2023-05-07 18:33 ` Harald Anlauf
2023-05-08 0:13 ` Steve Kargl [this message]
2023-05-08 19:03 ` Harald Anlauf
2023-05-08 19:03 ` Harald Anlauf
2023-05-12 20:36 ` Jerry D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFg+tMT3WlFWNNpK@troutmask.apl.washington.edu \
--to=sgk@troutmask.apl.washington.edu \
--cc=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jvdelisle2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).