From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id DC96D3858D32; Mon, 8 May 2023 00:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC96D3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 3480Den5091786 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 7 May 2023 17:13:40 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 3480Deiv091785; Sun, 7 May 2023 17:13:40 -0700 (PDT) (envelope-from sgk) Date: Sun, 7 May 2023 17:13:40 -0700 From: Steve Kargl To: Harald Anlauf Cc: Jerry D , gfortran , gcc-patches Subject: Re: [patch, fortran] PR109662 Namelist input with comma after name accepted Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <508ee742-97fa-9f61-ab65-98d3fa8e7dca@gmx.de> <658d646d-d699-0d7c-06ce-396af393008f@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <658d646d-d699-0d7c-06ce-396af393008f@gmx.de> X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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