* [patch, fortran] PR109662 Namelist input with comma after name accepted @ 2023-05-06 3:41 Jerry D 2023-05-06 4:02 ` Steve Kargl 0 siblings, 1 reply; 11+ messages in thread From: Jerry D @ 2023-05-06 3:41 UTC (permalink / raw) To: gfortran; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 677 bytes --] 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? Regards, Jerry Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> Date: Fri May 5 20:12:25 2023 -0700 Fortran: Namelist read with invalid input accepted. PR fortran/109662 libgfortran/ChangeLog: * io/list_read.c: Add a check for a comma after a namelist name in read input. Issue a runtime error message. gcc/testsuite/ChangeLog: * gfortran.dg/pr109662.f90: New test. [-- Attachment #2: mysubmit.diff --] [-- Type: text/x-patch, Size: 1316 bytes --] diff --git a/gcc/testsuite/gfortran.dg/pr109662.f90 b/gcc/testsuite/gfortran.dg/pr109662.f90 new file mode 100644 index 00000000000..988cfab73cc --- /dev/null +++ b/gcc/testsuite/gfortran.dg/pr109662.f90 @@ -0,0 +1,15 @@ +! { dg-do run } +! { dg-options "-std=f2003" } +! PR109662 a comma after namelist name accepted on input. +program testnmlread + implicit none + character(16) :: list = '&stuff, n = 759/' + character(100)::message + integer :: n, ioresult + namelist/stuff/n + message = "" + ioresult = 0 + n = 99 + read(list,nml=stuff,iostat=ioresult) + if (ioresult == 0) STOP 13 +end program testnmlread diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c index 109313c15b1..78bfd9e8787 100644 --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -3596,8 +3596,12 @@ find_nml_name: if (dtp->u.p.nml_read_error) goto find_nml_name; - /* A trailing space is required, we give a little latitude here, 10.9.1. */ + /* A trailing space is required, we allow a comma with std=gnu. */ c = next_char (dtp); + if (c == ',' && !(compile_options.allow_std & GFC_STD_GNU)) + generate_error (&dtp->common, LIBERROR_READ_VALUE, + "Comma after namelist name not allowed"); + if (!is_separator(c) && c != '!') { unget_char (dtp, c); ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-06 3:41 [patch, fortran] PR109662 Namelist input with comma after name accepted Jerry D @ 2023-05-06 4:02 ` Steve Kargl 2023-05-06 18:15 ` Harald Anlauf 0 siblings, 1 reply; 11+ messages in thread From: Steve Kargl @ 2023-05-06 4:02 UTC (permalink / raw) To: Jerry D via Fortran; +Cc: gcc-patches 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. -- Steve ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 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 0 siblings, 2 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-06 18:15 UTC (permalink / raw) To: gcc-patches; +Cc: fortran 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. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-06 18:15 ` Harald Anlauf @ 2023-05-06 18:15 ` Harald Anlauf 2023-05-07 17:33 ` Jerry D 1 sibling, 0 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-06 18:15 UTC (permalink / raw) To: sgk, Jerry D via Fortran; +Cc: gcc-patches 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. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 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 1 sibling, 1 reply; 11+ messages in thread From: Jerry D @ 2023-05-07 17:33 UTC (permalink / raw) To: Harald Anlauf, sgk, gfortran; +Cc: gcc-patches 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 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 0 siblings, 2 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-07 18:33 UTC (permalink / raw) To: gcc-patches; +Cc: fortran [-- Attachment #1: Type: text/plain, Size: 6696 bytes --] 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 > > [-- Attachment #2: pr109662-xx.f90 --] [-- Type: text/x-fortran, Size: 1266 bytes --] 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-07 18:33 ` Harald Anlauf @ 2023-05-07 18:33 ` Harald Anlauf 2023-05-08 0:13 ` Steve Kargl 1 sibling, 0 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-07 18:33 UTC (permalink / raw) To: Jerry D, sgk, gfortran; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 6880 bytes --] 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 > > [-- Attachment #2: pr109662-xx.f90 --] [-- Type: text/x-fortran, Size: 1266 bytes --] 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-07 18:33 ` Harald Anlauf 2023-05-07 18:33 ` Harald Anlauf @ 2023-05-08 0:13 ` Steve Kargl 2023-05-08 19:03 ` Harald Anlauf 1 sibling, 1 reply; 11+ messages in thread From: Steve Kargl @ 2023-05-08 0:13 UTC (permalink / raw) To: Harald Anlauf; +Cc: Jerry D, gfortran, gcc-patches 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-08 0:13 ` Steve Kargl @ 2023-05-08 19:03 ` Harald Anlauf 2023-05-08 19:03 ` Harald Anlauf 2023-05-12 20:36 ` Jerry D 0 siblings, 2 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-08 19:03 UTC (permalink / raw) To: gcc-patches; +Cc: fortran Steve, On 5/8/23 02:13, Steve Kargl via Gcc-patches wrote: > 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. > please don't let us get off-topic. The issue behind the PR was F2018: 13.11.3.1, Namelist input, which has Input for a namelist input statement consists of (1) optional blanks and namelist comments, (2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST statement, (3) one or more blanks, where "blanks" was to be interpreted. Separators are discussed separately. Jerry has resolved "," and ";". Good. There is another weird issue that is visible in the testcase output in my previous mail for "!". Reducing that further now suggests that the EOF condition of the namelist read of the single line affects the namelist read of the next multi-line read. So this one is actually a different bug, likely libgfortran's internal state. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-08 19:03 ` Harald Anlauf @ 2023-05-08 19:03 ` Harald Anlauf 2023-05-12 20:36 ` Jerry D 1 sibling, 0 replies; 11+ messages in thread From: Harald Anlauf @ 2023-05-08 19:03 UTC (permalink / raw) To: sgk; +Cc: Jerry D, gfortran, gcc-patches Steve, On 5/8/23 02:13, Steve Kargl via Gcc-patches wrote: > 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. > please don't let us get off-topic. The issue behind the PR was F2018: 13.11.3.1, Namelist input, which has Input for a namelist input statement consists of (1) optional blanks and namelist comments, (2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST statement, (3) one or more blanks, where "blanks" was to be interpreted. Separators are discussed separately. Jerry has resolved "," and ";". Good. There is another weird issue that is visible in the testcase output in my previous mail for "!". Reducing that further now suggests that the EOF condition of the namelist read of the single line affects the namelist read of the next multi-line read. So this one is actually a different bug, likely libgfortran's internal state. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, fortran] PR109662 Namelist input with comma after name accepted 2023-05-08 19:03 ` Harald Anlauf 2023-05-08 19:03 ` Harald Anlauf @ 2023-05-12 20:36 ` Jerry D 1 sibling, 0 replies; 11+ messages in thread From: Jerry D @ 2023-05-12 20:36 UTC (permalink / raw) To: Harald Anlauf, sgk; +Cc: gfortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 702 bytes --] I plan to commit the following as simple. The issue was a value was being modified on a short namelist read. After tthe first read gives the correct EOF, a second read would give the error but modify the variable. diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c index 82664dc5f98..36d025949c2 100644 --- a/libgfortran/io/unit.c +++ b/libgfortran/io/unit.c @@ -504,6 +504,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit *iunit, int kind) iunit->current_record=0; iunit->read_bad = 0; iunit->endfile = NO_ENDFILE; + iunit->last_char = 0; /* Set flags for the internal unit. */ The revised test case attached. It has been regression tested OK. Regards, Jerry [-- Attachment #2: pr109662-a.f90 --] [-- Type: text/x-fortran, Size: 708 bytes --] ! { dg-do run } ! { dg-options "-std=f2003" } ! PR109662-a semi-colon after namelist name accepted on input. program testnmlread implicit none character(16) :: line = '&stuff; n = 759/' character(100)::message integer :: n, i, ioresult namelist/stuff/n message = "" ioresult = 0 n = 99 read(line,nml=stuff,iostat=ioresult) if (ioresult == 0) STOP 13 ! Should error with the semi-colon in there. ! Intentional short input (-> EOF) line = "&stuff" ! Problem manifests on two bad reads on same string. do i = 1, 6 n = -1 ioresult = 0 read (line,nml=stuff,iostat=ioresult) if (n /= -1) STOP 24 if (ioresult == 0) STOP 25 end do end program testnmlread ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-05-12 20:36 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-06 3:41 [patch, fortran] PR109662 Namelist input with comma after name accepted 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 2023-05-08 19:03 ` Harald Anlauf 2023-05-08 19:03 ` Harald Anlauf 2023-05-12 20:36 ` Jerry D
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).