https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120111
--- Comment #6 from john.harper at vuw dot ac.nz ---
Thank you. I haven't changed my LD_FORTRAN_PATH for a long time and the
only things in it are to do with intel/oneapi. But there are a lot of
lib64 directories in my system. How do I find whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120111
--- Comment #4 from john.harper at vuw dot ac.nz ---
Sorry if I did something wrong when installing gfortran 15 from source
tarball gcc-15.1.0.tar.xz in a Linux Ubuntu system. Maybe your gfortran 15
is not identical to the release I used. I cert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120111
Bug ID: 120111
Summary: program with bad format that compiles and runs
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
--- Comment #14 from john.harper at vuw dot ac.nz ---
The comma between A and F is still required by F2023 constraint C1302,
and gfortran 14.2.0 still compiles and runs the test program omitting it
even if the -std=f2023 option is used.
On Sun, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115884
--- Comment #2 from john.harper at vuw dot ac.nz ---
Thank you kargls. My test program compiled and ran OK with another
machine which has gfortran 14.1.1. My Ubuntu system doesn't make it
easy for me to upgrade from gfortran 13.1. That's not yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115884
Bug ID: 115884
Summary: overload when one specific subroutine has no arguments
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
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/105
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 the
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
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 requi
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 a
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
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 attac
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 h
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
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
Compone
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 a
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
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-f20
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 wouldn't
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 Har
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: fo
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) wou
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
Compone
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
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))
b
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: normal
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
Pr
37 matches
Mail list logo
