https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173
Keith Refson changed:
What|Removed |Added
CC||krefson at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56696
Bug #: 56696
Summary: Formatted (list-directed) input fails to signal end
of record
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48360
Summary: ICE on array assignment statement with allocatable LHS
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45889
--- Comment #7 from Keith Refson 2010-10-05
16:19:50 UTC ---
Steve - thanks for the workaround (In fact I had already discovered this).
Jerry: As Steve pointed out explicitly, the statement that fails to
compile is simply printing a character ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45889
--- Comment #4 from Keith Refson 2010-10-05
13:51:09 UTC ---
(In reply to comment #3)
> In the test case, does the SAVE automatically allocate? Where does the
> derived
> type get allocated ?. If it has not been allocated and set to some value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45889
Summary: Regression with I/O of element of allocatable array in
derived type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #4 from krefson at googlemail dot com 2008-01-20 13:53 ---
(In reply to comment #3)
> (In reply to comment #2)
> > It's a regression - and I might be guilty of it with my Bind(C) patches...
>
> Well, if it's a regression, there's a bigger chan
gnu dot org
ReportedBy: krefson at googlemail dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
