* [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
@ 2013-05-16 19:16 ` janus at gcc dot gnu.org
2013-07-26 15:14 ` janus at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-05-16 19:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-05-16
CC| |janus at gcc dot gnu.org
Summary|ICE on valid with class |[OOP] ICE on valid with
|pointer assignment |class pointer
| |initialization
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed with 4.7, 4.8 and trunk.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
2013-05-16 19:16 ` [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization janus at gcc dot gnu.org
@ 2013-07-26 15:14 ` janus at gcc dot gnu.org
2013-07-26 18:48 ` janus at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-26 15:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #2 from janus at gcc dot gnu.org ---
The following patch seems to fix it ...
Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c (revision 201253)
+++ gcc/fortran/trans-decl.c (working copy)
@@ -1491,14 +1491,15 @@ gfc_get_symbol_decl (gfc_symbol * sym)
SAVE is specified otherwise they need to be reinitialized
every time the procedure is entered. The TREE_STATIC is
in this case due to -fmax-stack-var-size=. */
+ bool ptr = sym->attr.pointer || sym->attr.allocatable
+ || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.pointer);
+
DECL_INITIAL (decl) = gfc_conv_initializer (sym->value, &sym->ts,
TREE_TYPE (decl),
sym->attr.dimension
|| (sym->attr.codimension
&& sym->attr.allocatable),
- sym->attr.pointer
- || sym->attr.allocatable,
- sym->attr.proc_pointer);
+ ptr, sym->attr.proc_pointer);
}
if (!TREE_STATIC (decl)
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
2013-05-16 19:16 ` [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization janus at gcc dot gnu.org
2013-07-26 15:14 ` janus at gcc dot gnu.org
@ 2013-07-26 18:48 ` janus at gcc dot gnu.org
2013-07-26 19:41 ` janus at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-26 18:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> The following patch seems to fix it ...
... but unfortunately ICEs on a number of tests, e.g. class_{13,18,33,34} and
others.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (2 preceding siblings ...)
2013-07-26 18:48 ` janus at gcc dot gnu.org
@ 2013-07-26 19:41 ` janus at gcc dot gnu.org
2013-07-29 21:19 ` [Bug fortran/57306] [OOP] [F08] " janus at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-26 19:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #4 from janus at gcc dot gnu.org ---
Here is an enhanced patch which regtests cleanly:
Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c (revision 201253)
+++ gcc/fortran/trans-decl.c (working copy)
@@ -1491,14 +1491,16 @@ gfc_get_symbol_decl (gfc_symbol * sym)
SAVE is specified otherwise they need to be reinitialized
every time the procedure is entered. The TREE_STATIC is
in this case due to -fmax-stack-var-size=. */
+ bool ptr = sym->attr.pointer || sym->attr.allocatable
+ || (sym->ts.type == BT_CLASS
+ && CLASS_DATA (sym)->attr.class_pointer);
+
DECL_INITIAL (decl) = gfc_conv_initializer (sym->value, &sym->ts,
TREE_TYPE (decl),
sym->attr.dimension
|| (sym->attr.codimension
&& sym->attr.allocatable),
- sym->attr.pointer
- || sym->attr.allocatable,
- sym->attr.proc_pointer);
+ ptr, sym->attr.proc_pointer);
}
if (!TREE_STATIC (decl)
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c (revision 201253)
+++ gcc/fortran/trans-expr.c (working copy)
@@ -5664,7 +5664,18 @@ gfc_conv_initializer (gfc_expr * expr, gfc_typespe
else if (pointer || procptr)
{
if (!expr || expr->expr_type == EXPR_NULL)
- return fold_convert (type, null_pointer_node);
+ {
+ if (ts->type == BT_CLASS)
+ {
+ gfc_init_se (&se, NULL);
+ gfc_conv_structure (&se, gfc_class_null_initializer(ts, expr), 1);
+ gcc_assert (TREE_CODE (se.expr) == CONSTRUCTOR);
+ TREE_STATIC (se.expr) = 1;
+ return se.expr;
+ }
+ else
+ return fold_convert (type, null_pointer_node);
+ }
else
{
gfc_init_se (&se, NULL);
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (3 preceding siblings ...)
2013-07-26 19:41 ` janus at gcc dot gnu.org
@ 2013-07-29 21:19 ` janus at gcc dot gnu.org
2013-07-31 19:49 ` janus at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-29 21:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[OOP] ICE on valid with |[OOP] [F08] ICE on valid
|class pointer |with class pointer
|initialization |initialization
--- Comment #5 from janus at gcc dot gnu.org ---
Btw, pointer init is an F08 feature ...
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (4 preceding siblings ...)
2013-07-29 21:19 ` [Bug fortran/57306] [OOP] [F08] " janus at gcc dot gnu.org
@ 2013-07-31 19:49 ` janus at gcc dot gnu.org
2013-07-31 19:52 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-31 19:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #6 from janus at gcc dot gnu.org ---
An updated patch was posted here:
http://gcc.gnu.org/ml/fortran/2013-07/msg00135.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (5 preceding siblings ...)
2013-07-31 19:49 ` janus at gcc dot gnu.org
@ 2013-07-31 19:52 ` janus at gcc dot gnu.org
2013-07-31 20:22 ` janus at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-31 19:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #7 from janus at gcc dot gnu.org ---
Here is a reduced version of the test case from
http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
still ICEs:
type :: c
end type c
type(c), target :: x
class(c), pointer :: px => x
if (.not. associated(px)) call abort()
end
internal compiler error: in expand_expr_real_1, at expr.c:9361
end
^
0x764cdd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/janus/gcc49/trunk/gcc/expr.c:9356
0x76b7b7 expand_expr
/home/janus/gcc49/trunk/gcc/expr.h:444
0x76b7b7 expand_expr_addr_expr_1
/home/janus/gcc49/trunk/gcc/expr.c:7587
0x762a59 expand_expr_addr_expr
/home/janus/gcc49/trunk/gcc/expr.c:7710
0x762a59 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/janus/gcc49/trunk/gcc/expr.c:10451
0xabcfca expand_expr
/home/janus/gcc49/trunk/gcc/expr.h:444
0xabcfca output_constant
/home/janus/gcc49/trunk/gcc/varasm.c:4665
0xabcfca output_constant(tree_node*, unsigned long, unsigned int)
/home/janus/gcc49/trunk/gcc/varasm.c:4566
0xabdb4b output_constructor_regular_field
/home/janus/gcc49/trunk/gcc/varasm.c:4912
0xabdb4b output_constructor
/home/janus/gcc49/trunk/gcc/varasm.c:5191
0xac1981 assemble_variable(tree_node*, int, int, int)
/home/janus/gcc49/trunk/gcc/varasm.c:2113
0xac2259 varpool_assemble_decl(varpool_node*)
/home/janus/gcc49/trunk/gcc/varpool.c:347
0x6d9f12 output_in_order
/home/janus/gcc49/trunk/gcc/cgraphunit.c:1788
0x6d9f12 compile()
/home/janus/gcc49/trunk/gcc/cgraphunit.c:2024
0x6da184 finalize_compilation_unit()
/home/janus/gcc49/trunk/gcc/cgraphunit.c:2106
0x82b04c write_global_declarations()
/home/janus/gcc49/trunk/gcc/langhooks.c:322
0x5f82bf gfc_write_global_declarations
/home/janus/gcc49/trunk/gcc/fortran/f95-lang.c:263
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (6 preceding siblings ...)
2013-07-31 19:52 ` janus at gcc dot gnu.org
@ 2013-07-31 20:22 ` janus at gcc dot gnu.org
2013-07-31 20:39 ` janus at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-31 20:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> Here is a reduced version of the test case from
> http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
> still ICEs:
>
>
> type :: c
> end type c
>
> type(c), target :: x
> class(c), pointer :: px => x
>
> if (.not. associated(px)) call abort()
> end
Putting this inside a subroutine, one gets:
class(c), pointer :: px => x
1
Error: Pointer initialization target at (1) must have the SAVE attribute
Giving 'x' the SAVE attribute makes both versions compile without error. I
guess the original version is still valid, since 'x' should implicitly get the
SAVE attribute [1]. However, without the explicit SAVE declaration, it is not
shown as 'static' in the dump.
[1] F08, section 5.3.16: "A variable, common block, or procedure pointer
declared in the scoping unit of a main program, module, or submodule implicitly
has the SAVE attribute, which may be confirmed by explicit specification."
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (7 preceding siblings ...)
2013-07-31 20:22 ` janus at gcc dot gnu.org
@ 2013-07-31 20:39 ` janus at gcc dot gnu.org
2013-08-01 21:32 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-31 20:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Giving 'x' the SAVE attribute makes both versions compile without error. I
> guess the original version is still valid, since 'x' should implicitly get
> the SAVE attribute [1]. However, without the explicit SAVE declaration, it
> is not shown as 'static' in the dump.
Problem is: We currently don't make variables in the main program SAVE_IMPLICT
yet.
There is a patch in PR 55207 comment 3 which does this. Applying it (in
addition to the patch from comment 6) makes the ICE in comment 7 go away.
Unfortunately it had a couple of regressions, see in particular PR 55207
comment 6.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (8 preceding siblings ...)
2013-07-31 20:39 ` janus at gcc dot gnu.org
@ 2013-08-01 21:32 ` burnus at gcc dot gnu.org
2013-08-01 21:43 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-08-01 21:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> Putting this inside a subroutine, one gets:
>
> class(c), pointer :: px => x
> 1
> Error: Pointer initialization target at (1) must have the SAVE attribute
That sounds like a bug:
"Explicit initialization of a variable that is not in a common block implies
the SAVE attribute, which may be confirmed by explicit specification." (5.2.3
Initialization, F2008)
And "px" is clearly initialized - see R505 and "The appearance of
initialization in an entity-decl for an entity without the PARAMETER attribute
speci\fes that
the entity is a variable with explicit initialization."
>From gcc-bugs-return-427134-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 01 21:40:40 2013
Return-Path: <gcc-bugs-return-427134-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22161 invoked by alias); 1 Aug 2013 21:40:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22068 invoked by uid 48); 1 Aug 2013 21:40:36 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55207] Automatic deallocation of variables declared in the main program
Date: Thu, 01 Aug 2013 21:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55207-4-qxKUZqnPz1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55207-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55207-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00058.txt.bz2
Content-length: 498
http://gcc.gnu.org/bugzilla/show_bug.cgi?idU207
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
>
> + if ((gfc_current_state () == COMP_MODULE
> + || gfc_current_state () == COMP_PROGRAM)
>
> I haven't tried the patch, but does it work correctly with BLOCK? (It might
> well be valid.)
Without actually trying it: I would say it should work, since a BLOCK construct
would imply COMP_BLOCK here, so that the save attribute is not set ...
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (9 preceding siblings ...)
2013-08-01 21:32 ` burnus at gcc dot gnu.org
@ 2013-08-01 21:43 ` janus at gcc dot gnu.org
2013-08-02 6:47 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-01 21:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> >
> > class(c), pointer :: px => x
> > 1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
>
> That sounds like a bug:
Ah, good point. Clearly we need to make sure that px gets marked as
SAVE_IMPLICIT here! Somehow I missed this on the first glance ...
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (10 preceding siblings ...)
2013-08-01 21:43 ` janus at gcc dot gnu.org
@ 2013-08-02 6:47 ` janus at gcc dot gnu.org
2013-08-06 8:21 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-02 6:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> >
> > class(c), pointer :: px => x
> > 1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
>
> That sounds like a bug:
>
> "Explicit initialization of a variable that is not in a common block implies
> the SAVE attribute, which may be confirmed by explicit specification."
> (5.2.3 Initialization, F2008)
>
> And "px" is clearly initialized
Oh, wait: The error is about the *target*, not the pointer. Therefore I think
it's indeed correct and there is no bug!
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (11 preceding siblings ...)
2013-08-02 6:47 ` janus at gcc dot gnu.org
@ 2013-08-06 8:21 ` janus at gcc dot gnu.org
2013-08-06 8:26 ` janus at gcc dot gnu.org
2013-08-06 16:28 ` abensonca at gmail dot com
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-06 8:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Aug 6 08:20:17 2013
New Revision: 201521
URL: http://gcc.gnu.org/viewcvs?rev=201521&root=gcc&view=rev
Log:
2013-08-06 Janus Weil <janus@gcc.gnu.org>
PR fortran/57306
* class.c (gfc_class_null_initializer): Rename to
'gfc_class_initializer'. Treat non-NULL init-exprs.
* gfortran.h (gfc_class_null_initializer): Update prototype.
* trans-decl.c (gfc_get_symbol_decl): Treat class variables.
* trans-expr.c (gfc_conv_initializer): Ditto.
(gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.
2013-08-06 Janus Weil <janus@gcc.gnu.org>
PR fortran/57306
* gfortran.dg/pointer_init_8.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/pointer_init_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (12 preceding siblings ...)
2013-08-06 8:21 ` janus at gcc dot gnu.org
@ 2013-08-06 8:26 ` janus at gcc dot gnu.org
2013-08-06 16:28 ` abensonca at gmail dot com
14 siblings, 0 replies; 16+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-06 8:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from janus at gcc dot gnu.org ---
r201521 basically fixes this PR (the remaining problem of comment 7 will be
tracked by PR 55207). Closing.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
2013-05-16 18:52 [Bug fortran/57306] New: ICE on valid with class pointer assignment abensonca at gmail dot com
` (13 preceding siblings ...)
2013-08-06 8:26 ` janus at gcc dot gnu.org
@ 2013-08-06 16:28 ` abensonca at gmail dot com
14 siblings, 0 replies; 16+ messages in thread
From: abensonca at gmail dot com @ 2013-08-06 16:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #15 from Andrew Benson <abensonca at gmail dot com> ---
Thanks for fixing!
^ permalink raw reply [flat|nested] 16+ messages in thread