public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).