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
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&
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
Created attachment 58639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58639&action=edit
The program:
In this program the generic name g
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:
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.
cha
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:
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
: 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
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
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
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
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 tol
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
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.66000
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='COMM
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 pre
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
> S
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
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
: 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
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
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
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
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
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 t
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
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
In the following program, F2008 constraint C1002 requires a comma between A and
F edit descriptors in a format, but the program without it compiled and ran as
if
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
On compiling this program with gfortran 7.2.1 the error message below it
appears. Is it a duplicate of bug 68155?
cayley[~/Jfh] % cat gfbug8.f90
program testgf
implicit none
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
IMHO This program is valid f2008 but gfortran won't compile it. Evidence:
cayley[~/Jfh] % cat cplx.f90
! Works with ifort -stand f95 but not gfortran -std=
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
-fcheck=bounds doesn't complain if LHS and RHS of real array assignments in a
subroutine are different s
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
Internal compiler error presumably due to a character parameter array
constructor.
The program (6 lines):
program ice ! f2003
implicit none
character
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
This program is bad because it has an assumed-shape array in an initialization
expression, but gfortran wrongly diagnoses it as a deferred array. Bug 46299
(in which gfortran
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
If array parameters are declared with both quad and double precision, the quad
one triggers a -Wconversion warning but the program's output shows that the
conve
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
This program violates f2008 syntax rule 7.2.1.2(4) but gfortran 6.1.1 on an
x86-64 system compiles and runs it, printing 0
program emptyarray5
implicit
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
Target Milestone: ---
Stop codes changed from the f2003 standard to f2008. The first of these 2
programs has a stop code valid in f2003 but not in f2008, the second has a stop
code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
john.harper at vuw dot ac.nz changed:
What|Removed |Added
CC||john.harper at vuw dot
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: john.harper at vuw dot ac.nz
gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with selected_real_kind(1)
but it ought to give real(8) because that is the smallest decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174
Bug #: 55174
Summary: internal compiler error: Segmentation fault with bad
array reference
Classification: Unclassified
Product: gcc
Version: unknown
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52101
Bug #: 52101
Summary: Obsolescence warning for non-obs. feature character
name*length
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52062
Bug #: 52062
Summary: [4.6.2 regression] public generic name, specific
functions of private types
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51418
Bug #: 51418
Summary: Fortran format sp,f0.0 output wrong with NaN and 0.0
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022
john.harper at vuw dot ac.nz changed:
What|Removed |Added
CC||john.harper at vuw dot
50 matches
Mail list logo
