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
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=55501
john.harper at vuw dot ac.nz changed:
What|Removed |Added
CC||john.harper at vuw dot
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
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:
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
: 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
conversion
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
: 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
: 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 shapes
: 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: ---
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=f2008
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
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
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
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
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
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 #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
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=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 #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 #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
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 #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
: 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
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
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=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
: 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=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
>
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 #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 #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 #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
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
: 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=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
--- 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 #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 +0
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=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.
characte
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:
47 matches
Mail list logo
