--- Comment #7 from terry at chem dot gu dot se 2010-03-06 03:36 ---
Subject: Re: [4.3/4.4/4.5 Regression] No EOF condition
if reading with '(x)' from an empty file
> Also the F95 standard says in 10.6.1:
>
> "The position specified by an X edit descri
3
ended
[...@rscpc28 ReadTest]$
as expected.
This is killing a large, multi-group quantum dynamics research code.
--
Summary: Read no longer jumps on end
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
--- Comment #3 from terry at chem dot gu dot se 2009-03-29 23:50 ---
Not a dupe of PR20520. That one is for questionable code producing (or not)
some unexpected (to some) output, and crashing when run. This is illegal code
that compiles AND RUNS quietly. Here unallocated is giving
--- Comment #8 from terry at chem dot gu dot se 2009-02-17 04:51 ---
It's not as frivolous as it sounds. ;-)
If it is indeed illegal not to obey an explicit interface (and though I can't
see anywhere in the standard that says this, the standard is pretty stupid if
it's
--- Comment #6 from terry at chem dot gu dot se 2009-02-16 00:43 ---
Can someone with a better understanding of the standard than me comment as to
whether this is actually legal Fortran when there is an explicit interface
known? It certainly fails any principle of least surprise
--- Comment #2 from terry at chem dot gu dot se 2009-02-16 00:36 ---
Well, that's rather embarrassing. But it does illustrate this hasn't been
fixed since I reported it in 2007.
PR 27989 is different, as there is no explicit interface in that case.
*** This bug has been m
--- Comment #5 from terry at chem dot gu dot se 2009-02-16 00:36 ---
*** Bug 39195 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
runtime
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39195
UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36761
rry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
--- Comment #4 from terry at chem dot gu dot se 2008-07-02 05:11 ---
(In reply to comment #3)
> I am not sure which patch did this, but I doubt it will be backported to 4.3
It already is in 4.3. ;-) As I said earlier, that warning is produced, but
easy to make go away with
inte
--- Comment #2 from terry at chem dot gu dot se 2008-07-02 02:10 ---
A gentle reminder: This problem still exists as of 4.3.2 20080626.
(At least a compile-time warning is generated for Daniel's testcase. If that
1000 index is an integer variable, however, the compile-time wa
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36683
--- Comment #4 from terry at chem dot gu dot se 2008-05-28 02:00 ---
Somewhat reduced testcase that exhibits the same behaviour:
program distgeom
implicit none
real(kind=8),dimension(7,12)::B
real(kind=8),dimension(7,7)::U
real(kind=8),dimension(6,12)::dzeta
call random_number(U)
call
--- Comment #9 from terry at chem dot gu dot se 2008-01-23 23:00 ---
Actually, with bad parentheses it's easy to generate strange error messages:
do while ((.true.)
1
Error: Invalid character in name at (1)
do while (.true.
1
Error: Unclassifiable statement at (1)
--- Comment #8 from terry at chem dot gu dot se 2008-01-23 21:54 ---
Rather than open a new bug, I'll tack onto this one as it's pretty much the
same bug in a different context.
The latest gfortran does indeed give a sensible error for the test case above.
However, if we put
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34676
unds runtime
error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host tr
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34325
--- Comment #4 from terry at chem dot gu dot se 2007-12-02 20:20 ---
You're outputting an array of point structures. First the first element (a
point), then the next, and so on. Why would you expect a different result?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34306
--- Comment #1 from terry at chem dot gu dot se 2007-11-28 10:33 ---
> gfortran behaves correctly with an explicit INTERFACE, but that
> should not be required (as far as I know)
Explicit interfaces are required for procedures with optional arguments. SUB
is still external to MA
--- Comment #4 from terry at chem dot gu dot se 2007-11-27 22:56 ---
(In reply to comment #3)
(Admittedly from the 4.2.2 manual):
2.2 Options controlling Fortran dialect
-frange-check
Enable range checking on results of simplification of constant expressions
during compilation. For
--- Comment #3 from terry at chem dot gu dot se 2007-11-27 22:23 ---
> I don't worry about "len=3", I'm worrying about the type:
>
> data emname/'bar'/
>
> is implicitly types REAL and then one line later comes:
>
> character(len
--- Comment #1 from terry at chem dot gu dot se 2007-11-27 22:12 ---
But a character string is not an array. The len parameter is a type parameter.
That part of the standard does not apply. It's legal.
--
terry at chem dot gu dot se changed:
What|Re
--- Comment #2 from terry at chem dot gu dot se 2007-11-27 21:57 ---
(In reply to comment #1)
> There is no bug here. You have explicitly disabled
> range checking. This means that you no longer have
> a limitation on range in constant folding. It may
> be help to lo
--- Comment #6 from terry at chem dot gu dot se 2007-11-16 20:57 ---
I'd just like to remind everyone that this is still an issue in gcc version
4.3.0 20071109
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
--- Comment #3 from terry at chem dot gu dot se 2007-11-15 10:27 ---
(In reply to comment #2)
> *** Bug 34092 has been marked as a duplicate of this bug. ***
>
So, to summarise: Unused parameters have been fixed in general, but unused
private module entities remain undetected
--- Comment #2 from terry at chem dot gu dot se 2007-11-15 10:19 ---
(In reply to comment #1)
> Duplicate of PR 31124 ?
>
Yar. I was misled the last time by the fact that PR 31129 also existed. The
parameter case has been fixed, but not the private case.
*** This bug ha
--- Comment #2 from terry at chem dot gu dot se 2007-11-15 10:19 ---
*** Bug 34092 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124
: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34092
Summary: ICE with constant intrinsic array specs
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at c
--- Comment #1 from terry at chem dot gu dot se 2007-06-14 15:24 ---
Or maybe not. If x is explicitly 5-element in GetEpsR (no reference to Nr) the
ICE still occurs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32343
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32343
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32323
--- Comment #3 from terry at chem dot gu dot se 2007-06-13 16:23 ---
(In reply to comment #2)
> Neither SUN nor Intel fortran compilers issue such a warning.
>
Indeed. That does not imply that gfortran shouldn't, though. Hence the
enhancement request.
--
http://
--- Comment #2 from terry at chem dot gu dot se 2007-06-13 16:10 ---
Ah. Of course explicit interfaces are required for automatic array arguments.
My Fortran-Fu seems to be deserting me at the moment. :-(
--
terry at chem dot gu dot se changed:
What|Removed
: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32319
--- Comment #1 from terry at chem dot gu dot se 2007-06-13 13:43 ---
(Whoops. Mixed up output in that last post. Only 8 reals are printed in
reality. My bad.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
licit interface
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-un
--- Comment #8 from terry at chem dot gu dot se 2007-05-04 18:37 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (I guess I should qualify that. I don't have a copy of the standard laying
> > around to check, but it's legal according to the Ellis, P
--- Comment #7 from terry at chem dot gu dot se 2007-05-04 18:35 ---
Created an attachment (id=13508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13508&action=view)
Revised nnh.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #6 from terry at chem dot gu dot se 2007-05-04 18:35 ---
Created an attachment (id=13507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13507&action=view)
Revised acmod.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #4 from terry at chem dot gu dot se 2007-05-04 17:50 ---
(I guess I should qualify that. I don't have a copy of the standard laying
around to check, but it's legal according to the Ellis, Philips and Lahey
book.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #3 from terry at chem dot gu dot se 2007-05-04 17:46 ---
While being a reasonably uncommon case, AFAICT it's a legal construct. That
is: not invalid code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31731
ran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #1 from terry at chem dot gu dot se 2007-03-11 01:57 ---
I've filed #31129 specifically for the parameter case. This is unrelated to
the private attribute.
--
terry at chem dot gu dot se changed:
What|Removed |
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
--- Comment #4 from terry at chem dot gu dot se 2007-03-09 21:29 ---
It seems the "x86 is stupid, see bug 323" blinkers have come down.
I'm not asking for anyone to alter any gcc code generation. I specifically
don't want the FP in software mentioned by kargl
--- Comment #2 from terry at chem dot gu dot se 2007-03-09 20:23 ---
Andrew, this is not a duplicate of #323.
I know why floating point results differ. I know there are
architecture-specific options that result in a more consistent floating point
model. (As far as I know, -ffloat
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
tions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
GCC build triplet: x86_64-unknown-linu
52 matches
Mail list logo
