emental procedure in genericl interface incorrectly
selected in preference to specific procedure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unass
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
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
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: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #2 from Ian Harvey 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 on) of
read that is the companion t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393
--- Comment #4 from Ian Harvey 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) :: var
READ ('(A)'), var
PR
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
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
: 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
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
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 explic
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=44265
--- Comment #9 from Ian Harvey ---
Created attachment 38708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38708&action=edit
Updated patch against r23740
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 #14 from Ian Harvey ---
I wouldn't know where to start with respect to the internal compiler error.
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
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
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
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 of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
--- Comment #3 from Ian Harvey ---
Why has this been marked as invalid?
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
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127
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=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,
Component: 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=19819&action=view)
Simple test case
Call the resulting program with an argument longer than one character.
--
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
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` in the
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
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 |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
--- Comment #8 from Ian Harvey ---
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 of an expression that is an actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56459
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
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 as
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 for the
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=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=19532&action=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 of
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=19655&action=view)
Source code that demonstrates the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
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
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265
--- Comment #2 from Ian Harvey 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 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 explanation, but
it got lost when
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
C
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
with reference to parameter array in
specification expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70864
Ian Harvey changed:
What|Removed |Added
CC||ian_harvey at bigpond dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71580
Ian Harvey changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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&action=edit
Reduced test case program exhibit
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
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 se
55 matches
Mail list logo
