https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #6 from Ian Harvey ---
A module procedure is defined by a module subprogram (F2018 15.2.2.2p3). A
module subprogram (or any subprogram) is a syntax element (a piece of source
code), equivalent to /module-subprogram/ (see the first
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
When compiling the following, recent master (and 10.2.1) issues an error
Error: Derived type declaration with FINAL at (1) must
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
F2018 removed the previous syntax restriction (F2008 C1245) on a subprogram
definition with both ELEMENTAL and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646
--- Comment #2 from Ian Harvey ---
The spurious warning is issued regardless of whether warnings are requested or
not (i.e. it is reported with a command line of just `gfortran -c file.f90`).
The warning is issued even if -Wno-aliasing is
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following example:
MODULE m1
IMPLICIT NONE
PUBLIC :: False
PUBLIC :: True
CONTAINS
FUNCTION False() RESULT(b
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following:
MODULE m
IMPLICIT NONE
TYPE :: t
END TYPE t
CONTAINS
SUBROUTINE s
! To reproduce, both actual arguments must be TARGET
mal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The module:
MODULE m
IMPLICIT NONE
TYPE :: t
INTEGER :: comp
END TYPE t
CONTAINS
SUBROUTINE s
ASSOCIAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
When compiled with recent trunk, the attached demonstrates that the position of
a file is incorrect when a user defined derived type input procedure is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
--- Comment #3 from Ian Harvey ---
Why has this been marked as invalid?
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following, when compiled with gfortran recent trunk, generates an error
that indicates that parsing
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following, when compiled with recent trunk (r243219), generates output that
is missing the "name =" part of the name-value subsequence for the object
ty: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The attached, when compiled with gfortran recent trunk (r243203):
MODULE ma
IMPLICIT NONE
TYPE :: ta
INTEGER, A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71796
--- Comment #3 from Ian Harvey ---
If you want a test case that exhibits no run time error upon successful
compilation and linking, then replace the entire main program with an END
statement.
MODULE ma
IMPLICIT NONE
PRIVATE
TYPE, PUBLIC,
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following snippet, when compiled with gfortran recent trunk (r238061) or
6.1.1 results in an internal compiler error
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
Created attachment 38853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38853=edit
Reduced test case program exhibiting the l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71580
Ian Harvey changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70864
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
With trunk r237470 the following results in an internal compiler error
(sym->backend_decl is null at trans_decl.c:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #14 from Ian Harvey ---
I wouldn't know where to start with respect to the internal compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #10 from Ian Harvey ---
The patch discussed in #5 applies changes to the wrong location in
trans-decl.c. Corrected patch attached.
With this latest patch I see no variation in check-fortran test results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #9 from Ian Harvey ---
Created attachment 38708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38708=edit
Updated patch against r23740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #6 from Ian Harvey ---
The code in #5 is missing the initial parenthesised expression that exposes the
flaw in parsing logic - the left hand operand of the string concatenation needs
to be `('(')`, and not just the string literal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67472
Ian Harvey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 67472, which changed state.
Bug 67472 Summary: Finalizer not invoked for undefined and unreferenced local
variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67472
What|Removed
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
gfortran recent trunk r227512 does not invoke the finalizer for the local
variable `aa` of the internal procedure `internal
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
gfortran recent trunk r227512 does not invoke the finalizer for the intrinsic
assignment (as required by F2008 4.5.6.3p9) to the array section of `b
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
Target Milestone: ---
The following, when compiled with trunk r227476, results in a ICE:
program main
implicit none
type foo
integer :: bar = 99
end type
class(foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
Ian Harvey ian_harvey at bigpond dot com changed:
What|Removed |Added
CC||ian_harvey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
--- Comment #8 from Ian Harvey ian_harvey at bigpond dot com ---
For clarity - there is a difference between a procedure as an actual argument
and a procedure reference (something with parentheses and maybe arguments
following) that is part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56459
Ian Harvey ian_harvey at bigpond dot com changed:
What|Removed |Added
CC||ian_harvey
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
gfortran built from current trunk rejects the following with Error: User
operator procedure ‘tostring’ at (1) cannot be assumed
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
The following (from recent c.l.f discussion) compiles without error with trunk
r215574, despite the actual argument not meeting the requirements
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
gfortran build from very recent trunk does not appear to be correctly handling
the case when an object with allocatable components is self assigned and
defined assignment is accessible
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ian_harvey at bigpond dot com
The following example, when compiled with recent trunk:
MODULE m
IMPLICIT NONE
CONTAINS
SUBROUTINE sub(proc)
INTERFACE
PURE FUNCTION proc(x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #2 from Ian Harvey ian_harvey at bigpond dot com 2012-02-27
09:28:22 UTC ---
There is no unit number in that /read-stmt/, just a /format/ and one io item.
This is the second form (per the ordering in the syntax rules from F77
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #4 from Ian Harvey ian_harvey at bigpond dot com 2012-02-27
10:30:32 UTC ---
Maybe there's some additional cleverness going on then, because the following
equally contrived example:
PROGRAM ReadMeOne
IMPLICIT NONE
CHARACTER(10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
Bug #: 52393
Summary: Erroneous parse of read statement with parenthesised
expression in format
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48478
Summary: Valid array-constructor syntax rejected/invalid
accepted
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
Summary: Spurious recursive call error with type bound
procedure
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356
Summary: Erroneous procedure/intent error and ICE for class
dummy argument
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #2 from Ian Harvey ian_harvey at bigpond dot com 2010-10-29
23:20:42 UTC ---
Created attachment 22202
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22202
Possible patch for PR44265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #3 from Ian Harvey ian_harvey at bigpond dot com 2010-10-29
23:32:29 UTC ---
(In reply to comment #2)
Created attachment 22202 [details]
Possible patch for PR44265
Apologies - I wrote several paragraphs of reasonably coherent
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian_harvey at bigpond dot com
GCC build triplet: i686-pc-mingw32
GCC host
: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian_harvey at bigpond dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42996
--- Comment #1 from ian_harvey at bigpond dot com 2010-02-08 10:48 ---
Created an attachment (id=19819)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19819action=view)
Simple test case
Call the resulting program with an argument longer than one character.
--
http
ReportedBy: ian_harvey at bigpond dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-19 14:06 ---
Created an attachment (id=19655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19655action=view)
Source code that demonstrates the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
: ian_harvey at bigpond dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-10 23:21 ---
Created an attachment (id=19532)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19532action=view)
Example source that causes the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42684
--- Comment #2 from ian_harvey at bigpond dot com 2010-01-11 01:56 ---
Some primitive debugging: As directed by parse_contained, parsing and
subsequent processing of the use statement in other_proc (parse_progunit)
occurs prior to parsing of the add_b function and hence determination
to specific procedure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian_harvey at bigpond dot com
GCC build
55 matches
Mail list logo
