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
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
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
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 +
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:
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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)
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
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.
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))
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
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:
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
31 matches
Mail list logo
