[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #30 from john.harper at vuw dot ac.nz --- Thank you! On Fri, 8 Mar 2024, jvdelisle at gcc dot gnu.org wrote: > Date: Fri, 8 Mar 2024 00:30:51 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Fri, 8 Mar 2024 13:31:02 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > --- Comment #29 from Jerry DeLisle --- > Backported to 13 and closing. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #25 from john.harper at vuw dot ac.nz --- With that program Intel's two compilers (ifort and ifx) both print >.30D+01< >.30E+01< If your program removes the d0.2 stuff and changes e0.2 to es0.2e0, i.e. character(20) :: fmt character(9) :: buffer fmt = "(1a1,es0.2e0,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer end then both Intel compilers print what you seem to have hoped for: >3.00E+0< but my gfortran, gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04), prints >3.00< I won't argue about the difference between gfortran's >0.30D+1< and Intel's >.30D+01< because I have been caught before by whether the zero before the decimal point and the zero after the D are optional. The f2018 standard is not easy to read on this. I tried aocc-flang on your original program, and I ought to send them a bug report because it printed >< >< I don't have access to the NAG compiler or anyone else's flang. John On Thu, 25 Jan 2024, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 25 Jan 2024 22:21:01 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Fri, 26 Jan 2024 11:21:15 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #24 from Jerry DeLisle --- > Currently gfortran does the following: > > character(20) :: fmt > character(9) :: buffer > fmt = "(1a1,d0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > fmt = "(1a1,e0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > end > > > $ gfc question.f90 > $ ./a.out > >0.30D+1< > >0.30E+1< > > Why not: > > $ ./a.out > >3.00D+0< > >3.00E+0< > > What does Intel do? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #9 from john.harper at vuw dot ac.nz ---
This variant of my test program (now called test4) hangs with gfortran
but not with other compilers if iam is written to output_unit (like the
original version) or to a file with a different positive unit number, but
it does not hang if written to a file with a negative unit number obtained
by opening it with newunit=u. Its user has those 3 choices at run time.
I hope it helps you explore this oddity of gfortran.
program test4
use iso_fortran_env, only: output_unit
! Linux with f2008 (newunit=, execute_command_line, allocatable scalar)
implicit none
integer:: u = output_unit+20
character:: ch*1, line(2)*80
print "(A)",'Output from iam will go to unit u;', &
' u=output_unit if you enter a, or',&
' unit=u (u>0) if you enter b, or',&
' newunit=u (u<0) if you enter anything else.'
read "(A)", ch
if(ch=='a') then
u = output_unit
else if(ch=='b') then
open( unit=u,file='test4.out')
else
open(newunit=u,file='test4.out')
end if
print "(A,I0)",'Output from iam will be written to unit ',u
write(u,"(A,L2)")'I am john',iam('john')
write(u,"(A,L2)")'I am JOHN',iam('JOHN')
if(u/=output_unit) then
rewind u
read(u,"(A)") line
print "(A)", line
close(u,status='delete')
end if
contains
logical function iam( name)
character(*),intent(in)::name
integer estat
character(:),allocatable:: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
end function iam
end program test4
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 --- Comment #6 from john.harper at vuw dot ac.nz --- I know nothing about either applying gfortran patches or MatterMost but I'm willing to try. On Thu, 11 Jan 2024, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 11 Jan 2024 20:18:36 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/113313] execute_command_line hangs at run time > Resent-Date: Fri, 12 Jan 2024 09:18:48 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 > > Jerry DeLisle changed: > > What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #4 from Jerry DeLisle --- > I just started looking at this today. I will give the patch a spin in the next > few days and if tests OK I can commit. > > John, are you able tp apply Steve's patch and try it? If not would you like to > learn how? I can show people the ropes. We have a MatterMost workspace you > can join and I can linkup with you there. (I will send you an invite, just let > me know.) > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #3 from john.harper at vuw dot ac.nz ---
I suspect that valgrind complained because I had not given an else part
for the variable cmd. In my system the valgrind error message went away
when I declared and evaluated cmd as follows:
character(len(name)+50):: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'
On Thu, 11 Jan 2024, john.harper at vuw dot ac.nz wrote:
> Date: Thu, 11 Jan 2024 07:03:05 +
> From: john.harper at vuw dot ac.nz
> To: John Harper
> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
> Resent-Date: Thu, 11 Jan 2024 20:03:22 +1300 (NZDT)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> --- Comment #2 from john.harper at vuw dot ac.nz ---
> Thank you! You may wish to know that in my Ubuntu system the program
> runs properly if the function iam is used in an assignment statement not a
> print statement. (Fortran Discourse gave me the idea.) Revised program:
>
> program test2
> ! f2008 using execute_command_line and assuming Linux
> implicit none
> logical foo(2)
> foo = [iam('john'),iam('JOHN')]
> print "(A,L2)",'I am john',foo(1)
> print "(A,L2)",'I am JOHN',foo(2)
>
> contains
>
> logical function iam( name)
> character(*),intent(in)::name
> integer estat
> character(len(name)+38):: cmd
> cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
> call execute_command_line(cmd,exitstat=estat)
> iam = (estat==0)
> end function iam
> end program test2
>
> On Thu, 11 Jan 2024, kargl at gcc dot
> gnu.org wrote:
>
>> Date: Thu, 11 Jan 2024 05:49:10 +
>> From: kargl at gcc dot gnu.org
>> To: John Harper
>> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
>> Resent-Date: Thu, 11 Jan 2024 18:49:26 +1300 (NZDT)
>> Resent-From:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>>
>> kargl at gcc dot gnu.org changed:
>>
>> What|Removed |Added
>>
>> CC||kargl at gcc dot gnu.org
>>
>> --- Comment #1 from kargl at gcc dot gnu.org ---
>> Created attachment 57034
>> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57034=edit
>> patch to execute_command_line.c
>>
>> Code compiles and runs on FreeBSD. That said, I see
>>
>> % gfcx -o z a.f90 -g && ./z
>> I am john F
>> I am JOHN F
>> % valgrind ./z
>> ==18812== Memcheck, a memory error detector
>> ==18812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
>> ==18812== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
>> ==18812== Command: ./z
>> ==18812==
>> ==18812== Conditional jump or move depends on uninitialised value(s)
>> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
>> (execute_command_line.c:203)
>> ==18812==by 0x400B2A: iam.0 (a.f90:15)
>> ==18812==by 0x400BE1: MAIN__ (a.f90:5)
>> ==18812==by 0x400CEF: main (a.f90:6)
>> ==18812==
>> I am john F
>> ==18812== Conditional jump or move depends on uninitialised value(s)
>> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
>> (execute_command_line.c:203)
>> ==18812==by 0x400B2A: iam.0 (a.f90:15)
>> ==18812==by 0x400C8B: MAIN__ (a.f90:6)
>> ==18812==by 0x400CEF: main (a.f90:6)
>> ==18812==
>> I am JOHN F
>> ==18812==
>> ==18812== HEAP SUMMARY:
>> ==18812== in use at exit: 0 bytes in 0 blocks
>> ==18812== total heap usage: 26 allocs, 26 frees, 9,873 bytes allocated
>>
>> Looking at the code around line 203 suggests that there may be some confusion
>> with setting the error status. The attached patch allows the code to
>> run without the valgrind warnings.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #2 from john.harper at vuw dot ac.nz ---
Thank you! You may wish to know that in my Ubuntu system the program
runs properly if the function iam is used in an assignment statement not a
print statement. (Fortran Discourse gave me the idea.) Revised program:
program test2
! f2008 using execute_command_line and assuming Linux
implicit none
logical foo(2)
foo = [iam('john'),iam('JOHN')]
print "(A,L2)",'I am john',foo(1)
print "(A,L2)",'I am JOHN',foo(2)
contains
logical function iam( name)
character(*),intent(in)::name
integer estat
character(len(name)+38):: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
end function iam
end program test2
On Thu, 11 Jan 2024, kargl at gcc dot
gnu.org wrote:
> Date: Thu, 11 Jan 2024 05:49:10 +
> From: kargl at gcc dot gnu.org
> To: John Harper
> Subject: [Bug libfortran/113313] execute_command_line hangs at run time
> Resent-Date: Thu, 11 Jan 2024 18:49:26 +1300 (NZDT)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> kargl at gcc dot gnu.org changed:
>
> What|Removed |Added
>
> CC||kargl at gcc dot gnu.org
>
> --- Comment #1 from kargl at gcc dot gnu.org ---
> Created attachment 57034
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57034=edit
> patch to execute_command_line.c
>
> Code compiles and runs on FreeBSD. That said, I see
>
> % gfcx -o z a.f90 -g && ./z
> I am john F
> I am JOHN F
> % valgrind ./z
> ==18812== Memcheck, a memory error detector
> ==18812== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==18812== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
> ==18812== Command: ./z
> ==18812==
> ==18812== Conditional jump or move depends on uninitialised value(s)
> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
> (execute_command_line.c:203)
> ==18812==by 0x400B2A: iam.0 (a.f90:15)
> ==18812==by 0x400BE1: MAIN__ (a.f90:5)
> ==18812==by 0x400CEF: main (a.f90:6)
> ==18812==
> I am john F
> ==18812== Conditional jump or move depends on uninitialised value(s)
> ==18812==at 0x4B0AD79: _gfortran_execute_command_line_i4
> (execute_command_line.c:203)
> ==18812==by 0x400B2A: iam.0 (a.f90:15)
> ==18812==by 0x400C8B: MAIN__ (a.f90:6)
> ==18812==by 0x400CEF: main (a.f90:6)
> ==18812==
> I am JOHN F
> ==18812==
> ==18812== HEAP SUMMARY:
> ==18812== in use at exit: 0 bytes in 0 blocks
> ==18812== total heap usage: 26 allocs, 26 frees, 9,873 bytes allocated
>
> Looking at the code around line 203 suggests that there may be some confusion
> with setting the error status. The attached patch allows the code to
> run without the valgrind warnings.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz
[Bug fortran/113313] New: execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
Bug ID: 113313
Summary: execute_command_line hangs at run time
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
This program compiles and executes as expected with 3 other compilers (ifort,
ifx, flang). With gfortran 13.1.0 it compiles happily but prints nothing and
hangs at run time. My operating system is ubuntu1~22.04.
program test
! f2008 using execute_command_line and assuming Linux
implicit none
print "(A,L2)",'I am john',iam('john')
print "(A,L2)",'I am JOHN',iam('JOHN')
contains
logical function iam( name)
character(*),intent(in)::name
integer estat
character(len(name)+38):: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
end function iam
end program test
The other compilers all printed
I am john T
I am JOHN F
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #23 from john.harper at vuw dot ac.nz --- Jerry I agree that that's what the standard says, though I find it odd that it allows neither 666E0 nor 666E+0 nor 666+0 in output, because any of the three would be valid input of the real value 666. But you are editing a compiler to comply with the standard, and neither of us is editing the standard itself :-) John On Sun, 15 Oct 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 15 Oct 2023 02:12:25 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Sun, 15 Oct 2023 15:13:03 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #22 from Jerry DeLisle --- > Sorry for delays. I am back looking at this. > > My take on the table 13.2 for the case: EN0.0E0 > > No matter what the E for the exponent must be shown. > > If the exponent is 0 then a plus sign must be shown. > > The value for 666. then must be 666.E+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #20 from john.harper at vuw dot ac.nz --- With the first test case all the EN outputs were 666. but the Fortran 2018 standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 unless my copy of F2018 is out of date. (I note that the F2023 standard removed the ambiguity by including "with w > 0" in the offending line of Table 13.2.) However F2018 is unambiguous and agrees with F2023 on EN0.0E0, requiring 666.E+0 With the second test case, which used 66600, I think all Jerry's outputs are correct. On Mon, 4 Sep 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Mon, 4 Sep 2023 17:12:30 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Tue, 5 Sep 2023 05:12:45 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #18 from Jerry DeLisle --- > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent is > zero it is not shown at all. If I do specify an exponent width it shown. For > example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #15 from john.harper at vuw dot ac.nz --- My previous test program tried Ex0.0E0 output but not Ex0.0, where x is N,S, or absent. Below is a revised version which includes all 6 cases. It also tries EN and ES before trying E, with an error stop if an error is detected. Below the program is its output from ifort, which I think is f2018-compliant, compiled with options -standard-semantics -check all (All lines of gfortran output after the first appeared to be wrong.) program testen0es0e0 ! EN0.0,ES0.0 good f2018, E0.0 bad, with E0 or not integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & p3 = selected_real_kind(precision(1.0_p2)+1), & hp = selected_real_kind(precision(1.0_p3)+1), & p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 character:: ens(3)*2=["EN","ES"," E"],e0(2)*2=[" ","E0"], fmt*14, & msg*200 integer iens,ie0,ios write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 do iens = 1,3 do ie0 = 1,2 fmt = "(A,1X,"//ens(iens)//"0.0"//e0(ie0)//")" write(*, fmt,iostat=ios,iomsg=msg) 'With '//fmt, 666.0_p1 if(ios/=0) error stop trim(msg) write(*, fmt) 'With '//fmt, 666.0_p2 write(*, fmt) 'With '//fmt, 666.0_p3 if(p3/=p4) write(*, fmt) 'With '//fmt, 666.0_p4 end do end do end program testen0es0e0 real kinds 4 8 16 16 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X, E0.0 ) * output conversion error, unit 6, file /dev/pts/0 -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #14 from john.harper at vuw dot ac.nz --- To add to my email copied below, you may find a reference to the standards helpful. k is the scale factor referred to in F2018 or F2023 13.7.2.3.3. The last paragraph of that says that in Ew.d and Ew.dE0 output format, one of these two inequalities must be satisfied: -d < k <= 0 or 0 < k < d+2. With either E0.0 or E0.0E0 the value of k is not permitted. On Sun, 27 Aug 2023, john.harper at vuw dot ac.nz wrote: > Date: Sun, 27 Aug 2023 21:40:58 + > From: john.harper at vuw dot ac.nz > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 09:41:10 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #11 from john.harper at vuw dot ac.nz --- > Jerry's test program is identical with mine. > Because E format is supposed to give no digits before the decimal point > except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and > Steve Lionel pointed out in Fortran Discourse that the standard forbids > them because they would generate an illegal value of k for the kP edit > descriptor (which happens not to be explicitly used here.) So I think > gfortran ought to give a run-time error for it. If I compiled the program > with ifort and more warning options, the first 2 write statements gave > > real kinds 4 8 16 16 > With (A,1X, E0.0E0) * > forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 > > The ES result from gfortran was correct and standard-conforming. The EN > one should have said 666.E+0 not 666. > > On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > >> Date: Sun, 27 Aug 2023 15:38:33 + >> From: jvdelisle at gcc dot gnu.org >> To: John Harper >> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d >> too >> high. >> Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) >> Resent-From: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 >> >> --- Comment #9 from Jerry DeLisle --- >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >> p3 = selected_real_kind(precision(1.0_p2)+1), & >> hp = selected_real_kind(precision(1.0_p3)+1), & >> p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> >> -- >> You are receiving this mail because: >> You reported the bug. >> > > > -- John Harper, School of Mathematics and Statistics > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > e-mail john.har...@vuw.ac.nz > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #13 from john.harper at vuw dot ac.nz --- Hmmm. If I read anlauf correctly, our versions of ifort differ when writing ES0.0E0 and EN0.0E0 with the value 666.0. Both give the same correct numerical values but one version omits the E in the output. Omitting it does write the value in the shortest possible space but disobeys the F2018 and F2023 standards, where 13.7.2.3.4 Table 13.2 and 13.7.2.3.5 Table 13.3 require ENw.dE0 and ESw.dE0 to include E in the output. On Sun, 27 Aug 2023, anlauf at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 19:41:10 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 07:41:23 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #10 from anlauf at gcc dot gnu.org --- > (In reply to Jerry DeLisle from comment #9) >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >>p3 = selected_real_kind(precision(1.0_p2)+1), & >>hp = selected_real_kind(precision(1.0_p3)+1), & >>p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. > > Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives: > > real kinds 4 8 16 16 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #11 from john.harper at vuw dot ac.nz --- Jerry's test program is identical with mine. Because E format is supposed to give no digits before the decimal point except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and Steve Lionel pointed out in Fortran Discourse that the standard forbids them because they would generate an illegal value of k for the kP edit descriptor (which happens not to be explicitly used here.) So I think gfortran ought to give a run-time error for it. If I compiled the program with ifort and more warning options, the first 2 write statements gave real kinds 4 8 16 16 With (A,1X, E0.0E0) * forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 The ES result from gfortran was correct and standard-conforming. The EN one should have said 666.E+0 not 666. On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 15:38:33 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #9 from Jerry DeLisle --- > I am using this: > > program teste0es0en0 > integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & > p3 = selected_real_kind(precision(1.0_p2)+1), & > hp = selected_real_kind(precision(1.0_p3)+1), & > p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 > character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " > integer ifmt > write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 > do ifmt = 1,3 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 > if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 > end do > end program teste0es0en0 > > And I get the following output with some test patching: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #8 from john.harper at vuw dot ac.nz --- I couldn't see the program teste0es0en0.f90 that is in your bugzilla but I could see that it does have 691 bytes. So does one of the two versions that I now have in my own computer. The attachment to this email contains that version and what ifort did with it. (Of course E0.0E0 is illegal Fortran but ES0.0E0 and EN0.0E0 are OK according to both the f2018 and f2023 standards.) On Sat, 26 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sat, 26 Aug 2023 04:26:51 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Sat, 26 Aug 2023 16:27:07 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > Jerry DeLisle changed: > > What|Removed |Added > > Status|NEW |ASSIGNED > > --- Comment #7 from Jerry DeLisle --- > I don't have ifort installed at the moment. Would someone post the output from > ifort with teste0es0en0.f90 attached to this PR? Much appreciated. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #5 from john.harper at vuw dot ac.nz --- True. I reported the bug because in ESw.dEe output format all 3 of w,d,e may be 0, but gfortran then gave the right numerical result in the wrong format with my test programs. (I'm told NAG hasn't yet implemented ES0.0E0 but ifort has got it right.) On Wed, 16 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Wed, 16 Aug 2023 03:39:58 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Wed, 16 Aug 2023 15:40:09 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #4 from Jerry DeLisle --- > The relative text in the standard is: > > 13.7.2.1 General rules > --- snip --- > (6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the > specified value of the field width w may be zero. In such cases, the processor > selects the smallest positive actual field width that does not result in a > field filled with asterisks. The specified value of w shall not be zero on > input. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #2 from john.harper at vuw dot ac.nz --- Further information on this bug: it affects all four real kinds with all three of E0.0E0, ES0.0E0 and EN0.0E0 formats. My 15-line test program for that is attached. I hope it helps. On Tue, 15 Aug 2023, anlauf at gcc dot gnu.org wrote: > Date: Tue, 15 Aug 2023 19:45:06 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Wed, 16 Aug 2023 07:45:16 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > anlauf at gcc dot gnu.org changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 > CC||jvdelisle at gcc dot gnu.org > Component|fortran |libfortran > Keywords||wrong-code > Last reconfirmed||2023-08-15 > > --- Comment #1 from anlauf at gcc dot gnu.org --- > Confirmed. > > @Jerry: can you have a look? F2008 did not specify w=0 for the ES format; > this was added in F2018. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug fortran/111022] New: ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Bug ID: 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz Target Milestone: --- This 3-line Fortran program: print "(ES0.0E0)", -666e0 print "(ES0.0E0)", -666d0 end program printed -6.66000E+2 -6.66000E+2 but I think it should have printed -7.E+2 -7.E+2 which is what ifort printed with the same program.
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #16 from john.harper at vuw dot ac.nz --- Saw this only after my previous 2 replies, A semicolon in a namelist is not a separator between Fortran statements, but it takes the place of a comma between values when decimal='COMMA' in an open, read or write statement according to f2003 10.9 and 10.10, and 9.5.1 C928 says decimal= and nml= may both appear in a data transfer statement. John On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 7 May 2023 18:35:46 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it > Resent-Date: Mon, 8 May 2023 06:36:00 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 > > --- Comment #13 from Jerry DeLisle --- > (In reply to Jerry DeLisle from comment #12) > > That recent patch regression tests fine. I should mention, there is one of our > original test cases in gfortran.dg that does use a comma. We definitely have > see the comma used, but I have never seen a semi-colon. I think because it is > a newer feature allowing semicoln separators between FORTRAN statements on a > single line. (?) > > Regardless, I am ready to push this out to trunk. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #15 from john.harper at vuw dot ac.nz ---
Sorry: what I should have said was that
If and only if a comma after a namelist name was a pre-2003 possibility
for gfortran then it makes sense to reject a semicolon there when the
decimal edit mode is COMMA, which first got into the standard with f2003.
John H
On Sun, 7 May 2023, john.harper at vuw dot ac.nz wrote:
> Date: Sun, 7 May 2023 21:46:33 +
> From: john.harper at vuw dot ac.nz
> To: John Harper
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Mon, 8 May 2023 09:46:44 +1200 (NZST)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #14 from john.harper at vuw dot ac.nz ---
> Rejecting a semicolon after the namelist name even if the decimal edit
> mode is COMMA makes sense because COMMA was first allowed in f2003,
> provided that semicolons in namelist were a pre-f2003 legacy possibility.
>
> John H
>
> On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote:
>
>> Date: Sun, 7 May 2023 18:14:23 +
>> From: jvdelisle at gcc dot gnu.org
>> To: John Harper
>> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
>> Resent-Date: Mon, 8 May 2023 06:14:37 +1200 (NZST)
>> Resent-From:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>>
>> --- Comment #12 from Jerry DeLisle ---
>> A additional adjustment to reject the semi-colon always.
>>
>> diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
>> index 78bfd9e8787..db3330060ce 100644
>> --- a/libgfortran/io/list_read.c
>> +++ b/libgfortran/io/list_read.c
>> @@ -3598,9 +3598,9 @@ find_nml_name:
>>
>> /* 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))
>> + if ((c == ',' && !(compile_options.allow_std & GFC_STD_GNU)) || c == ';')
>> generate_error (>common, LIBERROR_READ_VALUE,
>> - "Comma after namelist name not allowed");
>> + "Non blank after namelist name not allowed");
>>
>> if (!is_separator(c) && c != '!')
>> {
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>
>
> -- John Harper, School of Mathematics and Statistics
> Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
> e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #14 from john.harper at vuw dot ac.nz ---
Rejecting a semicolon after the namelist name even if the decimal edit
mode is COMMA makes sense because COMMA was first allowed in f2003,
provided that semicolons in namelist were a pre-f2003 legacy possibility.
John H
On Sun, 7 May 2023, jvdelisle at gcc dot gnu.org wrote:
> Date: Sun, 7 May 2023 18:14:23 +
> From: jvdelisle at gcc dot gnu.org
> To: John Harper
> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it
> Resent-Date: Mon, 8 May 2023 06:14:37 +1200 (NZST)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
>
> --- Comment #12 from Jerry DeLisle ---
> A additional adjustment to reject the semi-colon always.
>
> diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
> index 78bfd9e8787..db3330060ce 100644
> --- a/libgfortran/io/list_read.c
> +++ b/libgfortran/io/list_read.c
> @@ -3598,9 +3598,9 @@ find_nml_name:
>
> /* 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))
> + if ((c == ',' && !(compile_options.allow_std & GFC_STD_GNU)) || c == ';')
> generate_error (>common, LIBERROR_READ_VALUE,
> - "Comma after namelist name not allowed");
> + "Non blank after namelist name not allowed");
>
> if (!is_separator(c) && c != '!')
> {
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #11 from john.harper at vuw dot ac.nz --- What about std=2008 ? On Sat, 6 May 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sat, 6 May 2023 14:45:39 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it > Resent-Date: Sun, 7 May 2023 02:45:51 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 > > Jerry DeLisle changed: > > What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #10 from Jerry DeLisle --- > This is fixed on trunk. > > To clarify, the comma is accepted as before with -std=legacy and -std=gnu. > > It is rejected with -std=f95, -std=2003, and -std=f2018. > > Cheers! > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #7 from john.harper at vuw dot ac.nz --- I hadn't thought about -std=gnu in this context but it would make sense for std=gnu to give a warning for comma after namelist name if std=legacy is going to allow it without one. You wouldn't then have to change the gfortran manual page. John On Thu, 4 May 2023, John Harper wrote: > Date: Thu, 4 May 2023 16:59:31 +1200 (NZST) > From: John Harper > To: jvdelisle at gcc dot gnu.org > Subject: Re: [Bug libfortran/109662] bad namelist input but gfortran accepted > it > > OK by me but I'm not in charge of gfortran! > > On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote: > >> Date: Thu, 4 May 2023 03:05:49 + >> From: jvdelisle at gcc dot gnu.org >> To: John Harper >> Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted >> it >> Resent-Date: Thu, 4 May 2023 15:05:59 +1200 (NZST) >> Resent-From: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 >> >> --- Comment #5 from Jerry DeLisle --- >> Is this acceptable: >> >> $ ./a.out >> Compiler version = GCC version 14.0.0 20230424 (experimental) >> Compiler options = -mtune=generic -march=x86-64 -Wpedantic >> -fpre-include=/usr/include/finclude/math-vector-fortran.h >> At line 9 of file pr109662.f90 >> Fortran runtime error: Comma after namelist name not allowed >> >> Should I allow it with -std=legacy? >> >> -- >> You are receiving this mail because: >> You reported the bug. >> > > > -- John Harper, School of Mathematics and Statistics > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276 > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 --- Comment #6 from john.harper at vuw dot ac.nz --- OK by me but I'm not in charge of gfortran! On Thu, 4 May 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 4 May 2023 03:05:49 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/109662] bad namelist input but gfortran accepted it > Resent-Date: Thu, 4 May 2023 15:05:59 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 > > --- Comment #5 from Jerry DeLisle --- > Is this acceptable: > > $ ./a.out > Compiler version = GCC version 14.0.0 20230424 (experimental) > Compiler options = -mtune=generic -march=x86-64 -Wpedantic > -fpre-include=/usr/include/finclude/math-vector-fortran.h > At line 9 of file pr109662.f90 > Fortran runtime error: Comma after namelist name not allowed > > Should I allow it with -std=legacy? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug fortran/109662] New: bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 Bug ID: 109662 Summary: bad namelist input but gfortran accepted it Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz Target Milestone: --- This program compiled and ran with the std=f2018 option though it has a comma between the namelist group name and the variable name, which I and ifort believe is non-standard. The program: program testnmlread use iso_fortran_env,only: compiler_version,compiler_options,output_unit implicit none character(16) :: list = ', n = 666/' integer :: n namelist/stuff/n print *,'Compiler version = ',trim(compiler_version()) print *,'Compiler options = ',trim(compiler_options()) read(list,nml=stuff) write(output_unit,nml=stuff) end program testnmlread The output: Compiler version = GCC version 12.1.0 Compiler options = -mtune=generic -march=x86-64 -g -std=f2018 -fpre-include=/usr/include/finclude/math-vector-fortran.h N=666, / Result of gfortran -v : Using built-in specs. COLLECT_GCC=gfortran-12 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)
[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186 --- Comment #2 from john.harper at vuw dot ac.nz --- The results I expected were that nearest(huge(sp1),-sp1) would be near huge(sp1)/(1+epsilon(sp1)), nearest(huge(dp1),-dp1) would be near huge(dp1)/(1+epsilon(dp1)), nearest(huge(ep1),-ep1) would be near huge(ep1)/(1+epsilon(ep1)), nearest(huge(qp1),-qp1) would be near huge(qp1)/(1+epsilon(qp1)). The results from gfortran were different from those by a factor near 2. On compiling with ifort I got results close to what I had expected, which is why I thought the bug was not in my program. The g95 compiler (now about 10 years old) gave results identical to those of ifort except for ep = selected_real_kind(18) which ifort treats as if it were selected_real_kind(33) because ifort has only three real kinds. By the way I thought I was using gfortran 12.0. Compiling with -v said GNU Fortran (Ubuntu 12.1.0-2ubuntu1~22.04) version 12.1.0 (x86_64-linux-gnu) I wish to apologise for that error in my bug report. I got the same output on another machine with GNU Fortran (GCC) version 12.2.0 (x86_64-pc-linux-gnu) The factor 2 discrepancies become clearer in this version of my program, which has 4 more lines printing huge/nearest for the 4 real kinds. program nearesttest3 implicit none integer,parameter::sp = kind(1.0), dp=kind(1d0), ncases = 2, & ep = selected_real_kind(18),qp = selected_real_kind(33) character(*),parameter:: fmt(4) = & "(A,ES"//["16.08E2","26.17E3","30.20E4","44.34E4"]//")" character(24),dimension(2):: splist,dplist,eplist,qplist integer n real(sp),parameter::sp1 = 1.0_sp real(sp):: spx(ncases) = [huge(sp1),nearest(huge(sp1),-sp1)] data splist/'huge(sp1)','nearest(huge(sp1),-sp1)'/ real(dp),parameter::dp1 = 1.0_dp real(dp):: dpx(ncases) = [huge(dp1),nearest(huge(dp1),-dp1)] data dplist/'huge(dp1)','nearest(huge(dp1),-dp1)'/ real(ep),parameter::ep1 = 1.0_ep real(ep):: epx(ncases) = [huge(ep1),nearest(huge(ep1),-ep1)] data eplist/'huge(ep1)','nearest(huge(ep1),-ep1)'/ real(qp),parameter::qp1 = 1.0_qp real(qp):: qpx(ncases) = [huge(qp1),nearest(huge(qp1),-qp1)] data qplist/'huge(qp1)','nearest(huge(qp1),-qp1)'/ print fmt(1),(splist(n),spx(n),n=1,ncases) print fmt(1),'huge/nearest = ',huge(sp1)/nearest(huge(sp1),-sp1) print fmt(2),(dplist(n),dpx(n),n=1,ncases) print fmt(2),'huge/nearest = ',huge(dp1)/nearest(huge(dp1),-dp1) print fmt(3),(eplist(n),epx(n),n=1,ncases) print fmt(3),'huge/nearest = ',huge(ep1)/nearest(huge(ep1),-ep1) print fmt(4),(qplist(n),qpx(n),n=1,ncases) print fmt(4),'huge/nearest = ',huge(qp1)/nearest(huge(qp1),-qp1) end program nearesttest3 Its gfortran output: huge(sp1) 3.40282347E+38 nearest(huge(sp1),-sp1) 1.70141173E+38 huge/nearest = 2.E+00 huge(dp1) 1.79769313486231571E+308 nearest(huge(dp1),-dp1) 8.98846567431157854E+307 huge/nearest = 2.0E+000 huge(ep1) 1.18973149535723176502E+4932 nearest(huge(ep1),-ep1) 5.94865747678615882511E+4931 huge/nearest = 2.E+ huge(qp1) 1.1897314953572317650857593266280070E+4932 nearest(huge(qp1),-qp1) 5.9486574767861588254287966331400351E+4931 huge/nearest = 2.00E+ Its g95 output: uge(sp1) 3.40282347E+38 nearest(huge(sp1),-sp1) 3.40282326E+38 huge/nearest = 1.0012E+00 huge(dp1) 1.79769313486231571E+308 nearest(huge(dp1),-dp1) 1.79769313486231551E+308 huge/nearest = 1.00022E+000 huge(ep1) 1.18973149535723176502E+4932 nearest(huge(ep1),-ep1) 1.18973149535723176496E+4932 huge/nearest = 1.0011E+ huge(qp1) 1.1897314953572317650857593266280070E+4932 nearest(huge(qp1),-qp1) 1.1897314953572317650857593266280069E+4932 huge/nearest = 1.02E+ On Sun, 19 Mar 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 19 Mar 2023 05:06:47 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/109186] nearest(huge(x), > -1.0_kind(x)) half of correct value > Resent-Date: Sun, 19 Mar 2023 18:06:59 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186 > > Jerry DeLisle changed: > > What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #1 from Jerry DeLisle --- > Can you clarify what you expect the correct results should be that you expect? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug fortran/109186] New: nearest(huge(x),-1.0_kind(x)) half of correct value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186 Bug ID: 109186 Summary: nearest(huge(x),-1.0_kind(x)) half of correct value Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz Target Milestone: --- With all four real kinds available in gfortran_12 nearest(x,y) with x = huge and y = -1 this program gave about half the correct result. Ifort gave correct results for the 3 different kinds it has: sp,dp,qp. The program: implicit none integer,parameter::sp = kind(1.0), dp=kind(1d0), ncases = 2, & ep = selected_real_kind(18),qp = selected_real_kind(33) character(*),parameter:: fmt(4) = & "(A,ES"//["16.08E2","26.17E3","30.20E4","44.34E4"]//")" character(24),dimension(2):: splist,dplist,eplist,qplist integer n real(sp),parameter::sp1 = 1.0_sp real(sp):: spx(ncases) = [huge(sp1),nearest(huge(sp1),-sp1)] data splist/'huge(sp1)','nearest(huge(sp1),-sp1)'/ real(dp),parameter::dp1 = 1.0_dp real(dp):: dpx(ncases) = [huge(dp1),nearest(huge(dp1),-dp1)] data dplist/'huge(dp1)','nearest(huge(dp1),-dp1)'/ real(ep),parameter::ep1 = 1.0_ep real(ep):: epx(ncases) = [huge(ep1),nearest(huge(ep1),-ep1)] data eplist/'huge(ep1)','nearest(huge(ep1),-ep1)'/ real(qp),parameter::qp1 = 1.0_qp real(qp):: qpx(ncases) = [huge(qp1),nearest(huge(qp1),-qp1)] data qplist/'huge(qp1)','nearest(huge(qp1),-qp1)'/ print fmt(1),(splist(n),spx(n),n=1,ncases) print fmt(2),(dplist(n),dpx(n),n=1,ncases) print fmt(3),(eplist(n),epx(n),n=1,ncases) print fmt(4),(qplist(n),qpx(n),n=1,ncases) end program The output on ubuntu (Linux 86_64) huge(sp1) 3.40282347E+38 nearest(huge(sp1),-sp1) 1.70141173E+38 huge(dp1) 1.79769313486231571E+308 nearest(huge(dp1),-dp1) 8.98846567431157854E+307 huge(ep1) 1.18973149535723176502E+4932 nearest(huge(ep1),-ep1) 5.94865747678615882511E+4931 huge(qp1) 1.1897314953572317650857593266280070E+4932 nearest(huge(qp1),-qp1) 5.9486574767861588254287966331400351E+4931
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #21 from john.harper at vuw dot ac.nz --- I now have a new test case that avoids the possibility of recursive I/O by tstuff and fstuff doing internal writes to two different character variables. It still reveals the merge problem. It compiles and runs with gfortran-12 and ifort, giving different outputs. ! Must merge evaluate all 3 arguments? program testmerge10 implicit none character(7):: string(2) = ' ' logical:: x(2) = [.true., .false.], y integer i do i = 1,2 y = merge(tstuff(),fstuff(),x(i)) print *,y,string string = ' ' end do contains logical function tstuff() write(string(1),"(A)") ' tstuff' tstuff = .true. end function tstuff logical function fstuff() write(string(2),"(A)") ' fstuff' fstuff = .false. end function fstuff end program testmerge10 Good luck with your bughunt! John H On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote: > Date: Fri, 2 Dec 2022 21:05:43 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/107874] merge not using all its arguments > Resent-Date: Sat, 3 Dec 2022 10:05:53 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 > > --- Comment #19 from anlauf at gcc dot gnu.org --- > (In reply to john.harper from comment #18) >> An interesting problem! But I thought my original test case did not have >> recursive I/O because tstuff and fstuff each print something in the >> statement >> y = merge(tstuff(),fstuff(),x(i)) >> but y itself is printed only in the next statement, >> print *,y > > John, your original testcase in comment#0 was fine. > I tried to extend it to check for constant as well as non-constant mask, > and as you see I made a mistake by trying to make it smaller. Bad idea. > >> Or does evaluating merge allow each of tstuff and fstuff to be evaluated >> at the same time? I was thinking of tstuff and fstuff being evaluated >> in succession but could there be systems in which they are evaluated >> simultaneously? > > I don't recall having seen a mentioning in the standard of the order of > evaluation of different function (or subroutine) arguments. Do you? > > (Of course, if side-effects happen during that evaluation, such as I/O, > unexpected things may happen.) > >> If so, whether the program is valid Fortran depends on the >> kind of system on which it is being executed. > > Well, even if the print in tstuff/fstuff were a problem, one could construct > other testcases with side-effects that might be conforming. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have
recursive I/O because tstuff and fstuff each print something in the
statement
y = merge(tstuff(),fstuff(),x(i))
but y itself is printed only in the next statement,
print *,y
Or does evaluating merge allow each of tstuff and fstuff to be evaluated
at the same time? I was thinking of tstuff and fstuff being evaluated
in succession but could there be systems in which they are evaluated
simultaneously? If so, whether the program is valid Fortran depends on the
kind of system on which it is being executed.
John Harper
On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:
> Date: Fri, 2 Dec 2022 20:22:23 +
> From: anlauf at gcc dot gnu.org
> To: John Harper
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #17 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #16)
>> (In reply to anlauf from comment #15)
>> --- snip ---
>>> Can you please verify?
>>
>> Yes, this fixes the test case.
>
> OK, thanks for confirming.
>
>> However if the orginal test case is valid
>> fortran we probably need to fix something else. Paul Thomas was noticing a
>> similar problem with his Finalization patches. He was doing the
>> finalization inside trans_transfer or similar so it was blocking on a mutex
>> trying to finalize in the middle of an I/O operation.
>>
>> So in this case, my guess is the merge expression needs to be resolved
>> before the translation phase.
>
> If I interprete the tree-dump correctly, we have e.g.:
>
> _gfortran_st_write (_parm.2);
> {
>logical(kind=4) D.4279;
>logical(kind=4) D.4280;
>logical(kind=4) D.4281;
>logical(kind=4) D.4282;
>
>D.4279 = tstuff ();
>D.4280 = fstuff ();
>D.4281 = x[(integer(kind=8)) i + -1];
>D.4282 = D.4281 ? D.4279 : D.4280;
>_gfortran_transfer_logical_write (_parm.2, , 4);
> }
> _gfortran_st_write_done (_parm.2);
>
> so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
> and which does its own I/O, and then return to continue with the transfer.
>
> So this might be non-conforming code, see
>
> F2018:12.12 Restrictions on input/output statements
>
> (2) An input/output statement that is executed while another input/output
> statement is being executed is a recursive input/output statement.
> A recursive input/output statement shall not identify an external unit that
> is identified by another input/output statement being executed except that
> a child data transfer statement may identify its parent data transfer
> statement external unit.
>
> I am not sure I fully understand the last sentence in this paragraph,
> but I think the pushed testcase might be invalid and should be replaced.
>
> If you agree, I'll simply do this.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug fortran/107874] New: merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
Bug ID: 107874
Summary: merge not using all its arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
The F2018 standard 15.5.3 requires all actual arguments in a function reference
to be evaluated.
In the program below, merge has three scalar arguments; ifort evaluates
all three, gfortran evaluates only the useful two, which violates 15.5.3.
program testmerge9
implicit none
integer i
logical:: x(2)=(/.true., .false./), y ! avoiding [ ] allows f95 option
do i = 1,2
y = merge(tstuff(),fstuff(),x(i))
print *,y
end do
contains
logical function tstuff()
print *,'tstuff'
tstuff = .true.
end function tstuff
logical function fstuff()
print *,'fstuff'
fstuff = .false.
end function fstuff
end program testmerge9
Steve Kargl said "Looks like a bug. Feel free to send a bug report with this
patch."
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index bb938026828..c5b63d356e1 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -7538,9 +7538,9 @@ gfc_conv_intrinsic_merge (gfc_se * se, gfc_expr * expr)
gfc_conv_intrinsic_function_args (se, expr, args, num_args);
if (expr->ts.type != BT_CHARACTER)
{
- tsource = args[0];
- fsource = args[1];
- mask = args[2];
+ tsource = gfc_evaluate_now (args[0], >pre);
+ fsource = gfc_evaluate_now (args[1], >pre);
+ mask = gfc_evaluate_now (args[2], >pre);
}
else
{
[Bug fortran/105473] New: semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 Bug ID: 105473 Summary: semicolon allowed when list-directed read integer with decimal='point' Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: john.harper at vuw dot ac.nz Target Milestone: --- List-directed reading of a number should give an error if it reads a semicolon and decimal is not COMMA but this 9-line program gave the output shown below it. (The ifort compiler gave a positive value of ios, which I believe was correct.) ! Does list-directed reading an integer allow some non-integer input? implicit none integer n,ios character(1):: testinput = ';' print *,'testinput = "',testinput,'"' read(testinput,*,decimal='point',iostat=ios) n print *,'n=',n,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program john@johns-laptop:~/Jfh$ ./a.out testinput = ";" n= 1458129152 ios= 0 john@johns-laptop:~/Jfh$
[Bug fortran/100300] New: compile-time infinite loop if using execute_command_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100300
Bug ID: 100300
Summary: compile-time infinite loop if using
execute_command_line
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
The program writetest.f90 below writes a file and then uses
execute_command_line to compile readtest.f90, which was supposed to read the
file, but its syntax error drove gfortran into an infinite loop pointing the
error out. Linux system evidence:
cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
cayley[~/Jfh] % cat writetest.f90
! Use execute_command_line to start a second program readtest.f90 that
! reads a file, testfile.txt, written by this program.
implicit none
integer u,i
open(newunit=u,file='testfile.txt',action='WRITE',position='REWIND',&
form='FORMATTED',access='SEQUENTIAL')
write(u,"(A,I0)") ('line ',i,i=1,2)
call execute_command_line('gfortran readtest.f90 ; ./a.out')
end program
cayley[~/Jfh] % cat readtest.f90
implicit none
character(40) lines(2)
integer u
open(newunit=u,,file='testfile.txt')
read(u,"(A)") lines(:)
print "(A)",'readtest gave '//lines(:)
end program
The second program has a syntax error (,,) correctly found by gfortran but
compiling it by calling execute_command_line in the first program gave an
infinite loop repeating this 5-line message until I stopped it manually:
quote--
readtest.f90:4:18:
4 | open(newunit=u,,file='testfile.txt')
| 1
Error: Syntax error in OPEN statement at (1)
unquote
Correcting the error by removing one of the commas made the program compile
and run.
