* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-03 20:45 ` janus at gcc dot gnu.org
2011-02-03 20:56 ` janus at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-03 20:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #3 from janus at gcc dot gnu.org 2011-02-03 20:45:04 UTC ---
Test case:
type :: t
integer :: i
end type
class(t), allocatable :: x
type(t) :: y = t (3)
x = y
print *,x%i
end
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
2011-02-03 20:45 ` [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable janus at gcc dot gnu.org
@ 2011-02-03 20:56 ` janus at gcc dot gnu.org
2011-02-03 21:05 ` janus at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-03 20:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #4 from janus at gcc dot gnu.org 2011-02-03 20:56:10 UTC ---
Here is a simple patch for getting rid of the error message:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 169520)
+++ gcc/fortran/resolve.c (working copy)
@@ -8879,15 +8879,13 @@ resolve_ordinary_assign (gfc_code *code, gfc_names
gfc_current_ns->proc_name->attr.implicit_pure = 0;
}
- /* F03:7.4.1.2. */
- /* FIXME: Valid in Fortran 2008, unless the LHS is both polymorphic
- and coindexed; cf. F2008, 7.2.1.2 and PR 43366. */
- if (lhs->ts.type == BT_CLASS)
- {
- gfc_error ("Variable must not be polymorphic in assignment at %L",
- &lhs->where);
- return false;
- }
+ /* F03:7.4.1.2, F08:7.2.1.2. */
+ /* Valid in Fortran 2008, unless the LHS is both polymorphic and coindexed.
*/
+ if (lhs->ts.type == BT_CLASS
+ && gfc_notify_std (GFC_STD_F2008,
+ "Fortran 2008: Variable must not be polymorphic in "
+ "assignment at %L", &lhs->where) == FAILURE)
+ return false;
/* F2008, Section 7.2.1.2. */
if (gfc_is_coindexed (lhs) && gfc_has_ultimate_allocatable (lhs))
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
2011-02-03 20:45 ` [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable janus at gcc dot gnu.org
2011-02-03 20:56 ` janus at gcc dot gnu.org
@ 2011-02-03 21:05 ` janus at gcc dot gnu.org
2011-02-03 21:26 ` burnus at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-03 21:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |rejects-valid
CC| |pault at gcc dot gnu.org
--- Comment #5 from janus at gcc dot gnu.org 2011-02-03 21:04:47 UTC ---
Realloc-on-assign for scalars was implemented in r169356.
Paul, what does it take to make this work for polymorphic scalars?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-02-03 21:05 ` janus at gcc dot gnu.org
@ 2011-02-03 21:26 ` burnus at gcc dot gnu.org
2011-02-03 21:28 ` burnus at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-03 21:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-03 21:24:38 UTC ---
(In reply to comment #4)
> Here is a simple patch for getting rid of the error message:
The patch is not quite right. The LHS must be allocatable
("gfc_expr_attr(e).allocatable") - and it must not be coindexed
("!gfc_is_conindexed(e)").
Thus, you need something like:
if (lhs->ts.type == BT_CLASS)
{
if (gfc_expr_attr(e).allocatable") && !gfc_is_conindexed(e))
if (gfc_notify_std(F2008 ...) == FAILURE)
return false;
else
{
gfc_error ();
return false;
}
}
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-02-03 21:26 ` burnus at gcc dot gnu.org
@ 2011-02-03 21:28 ` burnus at gcc dot gnu.org
2011-02-03 21:29 ` burnus at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-03 21:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-03 21:28:10 UTC ---
(In reply to comment #4)
> Here is a simple patch for getting rid of the error message:
The patch is not quite right. The LHS must be allocatable and it must not be
coindexed nor a coarray - otherwise, an intrinsic allocate is not allowed.
Cf. "7.2.1.2 Intrinsic assignment statement": "(1) if the variable is
polymorphic it shall be allocatable and not a coarray," + quote in comment 0.
Thus, you need something like:
if (lhs->ts.type == BT_CLASS)
{
if (gfc_expr_attr(e).allocatable") && !gfc_is_coindexed(e)
&& !gfc_expr_attr(e).codimension)
{
if (gfc_notify_std(F2008 ...) == FAILURE)
return false;
}
else
{
gfc_error ();
return false;
}
}
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-02-03 21:28 ` burnus at gcc dot gnu.org
@ 2011-02-03 21:29 ` burnus at gcc dot gnu.org
2011-02-04 9:32 ` pault at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-03 21:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-03 21:29:12 UTC ---
(In reply to comment #6)
Stupid firefox - it somehow must have submitted a draft. Ignore comment 6 and
look at comment 7.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2011-02-03 21:29 ` burnus at gcc dot gnu.org
@ 2011-02-04 9:32 ` pault at gcc dot gnu.org
2011-02-10 22:43 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: pault at gcc dot gnu.org @ 2011-02-04 9:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-04 09:32:01 UTC ---
(In reply to comment #5)
> Realloc-on-assign for scalars was implemented in r169356.
>
> Paul, what does it take to make this work for polymorphic scalars?
Not a lot, I think. If you take a look in gfc_trans_allocate, there is a bit
that I think that you must have written, which initialises CLASS variables. I
would have thought that this can be lifted and deposited wholesale in
trans_assignment1 and gfc_trans_allocate reconfigured to use the assignement.
I am taking a look at gfc_trans_allocate this lunchtime; there's something not
quite right structurally with it. I attempted to add a patch of code to have a
single evaluation of the SOURCE expression and wound up displacing unrelated
declarations, when I added the se.post to the end of the main block. gimple did
not like it at all :-( I'll come back to you.
Cheers
Paul
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2011-02-04 9:32 ` pault at gcc dot gnu.org
@ 2011-02-10 22:43 ` janus at gcc dot gnu.org
2011-02-11 0:27 ` janus at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-10 22:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #10 from janus at gcc dot gnu.org 2011-02-10 22:41:47 UTC ---
The following patch makes the test case in comment #3 work correctly:
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c (revision 169986)
+++ gcc/fortran/trans-expr.c (working copy)
@@ -5838,6 +5838,14 @@ is_scalar_reallocatable_lhs (gfc_expr *expr)
&& !expr->ref)
return true;
+ /* An allocatable class variable with no reference. */
+ if (expr->symtree->n.sym->ts.type == BT_CLASS
+ && CLASS_DATA (expr->symtree->n.sym)->attr.allocatable
+ && expr->ref && expr->ref->type == REF_COMPONENT
+ && strcmp (expr->ref->u.c.component->name, "_data") == 0
+ && expr->ref->next == NULL)
+ return true;
+
/* All that can be left are allocatable components. */
if ((expr->symtree->n.sym->ts.type != BT_DERIVED
&& expr->symtree->n.sym->ts.type != BT_CLASS)
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 169987)
+++ gcc/fortran/resolve.c (working copy)
@@ -8881,14 +8881,32 @@ resolve_ordinary_assign (gfc_code *code, gfc_names
gfc_current_ns->proc_name->attr.implicit_pure = 0;
}
- /* F03:7.4.1.2. */
- /* FIXME: Valid in Fortran 2008, unless the LHS is both polymorphic
- and coindexed; cf. F2008, 7.2.1.2 and PR 43366. */
if (lhs->ts.type == BT_CLASS)
{
- gfc_error ("Variable must not be polymorphic in assignment at %L",
- &lhs->where);
- return false;
+ /* F08:7.2.1.2. */
+ if (!gfc_expr_attr (lhs).allocatable)
+ {
+ gfc_error ("Polymorphic variable in intrinsinc assignment must be "
+ "allocatable at %L", &lhs->where);
+ return false;
+ }
+ else if (gfc_expr_attr (lhs).codimension)
+ {
+ gfc_error ("Polymorphic variable in intrinsinc assignment must not be"
+ " coarray at %L", &lhs->where);
+ return false;
+ }
+ else if (gfc_is_coindexed (lhs))
+ {
+ gfc_error ("Polymorphic variable in intrinsinc assignment must not be"
+ " coindexed at %L", &lhs->where);
+ return false;
+ }
+ /* F03:7.4.1.2. */
+ else if (gfc_notify_std (GFC_STD_F2008, "Fortran 2008: Variable must not
"
+ "be polymorphic in assignment at %L",
+ &lhs->where) == FAILURE)
+ return false;
}
/* F2008, Section 7.2.1.2. */
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2011-02-10 22:43 ` janus at gcc dot gnu.org
@ 2011-02-11 0:27 ` janus at gcc dot gnu.org
2011-02-11 19:43 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-11 0:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #11 from janus at gcc dot gnu.org 2011-02-10 22:56:21 UTC ---
Stupid question, but shouldn't it be possible to replace the call to
'is_scalar_reallocatable_lhs' by a check for the allocatable attribute?
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c (revision 169986)
+++ gcc/fortran/trans-expr.c (working copy)
@@ -6116,8 +6087,7 @@
if (lss == gfc_ss_terminator)
{
/* F2003: Add the code for reallocation on assignment. */
- if (gfc_option.flag_realloc_lhs
- && is_scalar_reallocatable_lhs (expr1))
+ if (gfc_option.flag_realloc_lhs && gfc_expr_attr (expr1).allocatable)
alloc_scalar_allocatable_for_assignment (&block, rse.string_length,
expr1, expr2);
AFAICS, the routine does not do anything more anyway, right?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2011-02-11 0:27 ` janus at gcc dot gnu.org
@ 2011-02-11 19:43 ` burnus at gcc dot gnu.org
2011-07-22 12:09 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-11 19:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-11 19:38:23 UTC ---
(In reply to comment #10)
> The following patch makes the test case in comment #3 work correctly:
I think your current patch only works if declared type (LHS) == effective type
RHS. I think you need to use the size of the effective types ("_size"). The
change should be in trans-expr.c's alloc_scalar_allocatable_for_assignment. Cf.
"Determine allocate size" in trans-stmt.c's gfc_trans_allocate
(In reply to comment #11)
> Stupid question, but shouldn't it be possible to replace the call to
> 'is_scalar_reallocatable_lhs' by a check for the allocatable attribute?
I guess so - though I have not studied the code.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2011-02-11 19:43 ` burnus at gcc dot gnu.org
@ 2011-07-22 12:09 ` burnus at gcc dot gnu.org
2012-01-06 10:25 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-07-22 12:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-22 12:08:28 UTC ---
Regarding the LHS (in addition to comment 6):
- It may not be coindexed ("!gfc_is_conindexed(e)")
- It may not be a coarray ("!gfc_expr_attr (e).codimension")
- It may not have a coarray component ("!gfc_expr_attr (e).coarray_comp")
Cf. F2008, 7.2.1.2, item (1) and (3).
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2011-07-22 12:09 ` burnus at gcc dot gnu.org
@ 2012-01-06 10:25 ` burnus at gcc dot gnu.org
2012-02-09 17:52 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-01-06 10:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-06 10:24:24 UTC ---
As litmus test: BT_CLASS version of PR 50981: Passing an
unallocated/unassociated [or absent + nonpointer/nonallocatable] BT_CLASS
variable or a unallocated/unassociated BT_CLASS component to an
nonpointer/nonallocatable argument of an ELEMENTAL procedure.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2012-01-06 10:25 ` burnus at gcc dot gnu.org
@ 2012-02-09 17:52 ` burnus at gcc dot gnu.org
2012-04-10 21:06 ` abenson at caltech dot edu
` (2 subsequent siblings)
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-09 17:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-09 17:48:11 UTC ---
Created attachment 26628
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26628
Small patch for the resolve.c. It misses all the real work (trans*.c).
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2012-02-09 17:52 ` burnus at gcc dot gnu.org
@ 2012-04-10 21:06 ` abenson at caltech dot edu
2013-08-08 14:36 ` [Bug fortran/43366] [OOP][F08] " janus at gcc dot gnu.org
2013-09-18 18:15 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 18+ messages in thread
From: abenson at caltech dot edu @ 2012-04-10 21:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
Andrew Benson <abenson at caltech dot edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abenson at caltech dot edu
--- Comment #16 from Andrew Benson <abenson at caltech dot edu> 2012-04-10 21:06:13 UTC ---
The following compiles with "-std=f2003" and runs successfully (using gfortran
4.8 r186145) with the "a=b" line in, but if I switch it for the "a%d=b%d" line
I get a "Variable must not be polymorphic in intrinsic assignment at (1) -
check that there is a matching specific subroutine for '=' operator" error:
module testMod
implicit none
public t
type t
integer :: i
end type t
type c
class(t), allocatable :: d
end type c
end module testMod
program testProg
use testMod
implicit none
type(t) :: f
type(c) :: a,b
allocate(b%d,source=f)
b%d%i=12345
a=b !! THIS COMPILES OK
! a%d=b%d !! THIS DOES NOT
write (0,*) a%d%i
write (0,*) b%d%i
end program testProg
Since "d" is polymorphic both should be disallowed with "-std=f2003" (and both
allowed under F2008 I think).
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2012-04-10 21:06 ` abenson at caltech dot edu
@ 2013-08-08 14:36 ` janus at gcc dot gnu.org
2013-09-18 18:15 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-08 14:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
Bug 43366 depends on bug 46321, which changed state.
Bug 46321 Summary: [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable
[not found] <bug-43366-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2013-08-08 14:36 ` [Bug fortran/43366] [OOP][F08] " janus at gcc dot gnu.org
@ 2013-09-18 18:15 ` burnus at gcc dot gnu.org
15 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-09-18 18:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366
--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Sep 18 18:14:57 2013
New Revision: 202713
URL: http://gcc.gnu.org/viewcvs?rev=202713&root=gcc&view=rev
Log:
2013-09-15 Tobias Burnus <burnus@net-b.de>
PR fortran/43366
* primary.c (gfc_variable_attr): Also handle codimension.
* resolve.c (resolve_ordinary_assign): Add invalid-diagnostic
* for
polymorphic assignment.
2013-09-15 Tobias Burnus <burnus@net-b.de>
PR fortran/43366
* gfortran.dg/class_39.f03: Update dg-error.
* gfortran.dg/class_5.f03: Ditto.
* gfortran.dg/class_53.f90: Ditto.
* gfortran.dg/realloc_on_assign_20.f90: New.
* gfortran.dg/realloc_on_assign_21.f90: New.
* gfortran.dg/realloc_on_assign_22.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_20.f90
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_21.f90
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_39.f03
trunk/gcc/testsuite/gfortran.dg/class_5.f03
trunk/gcc/testsuite/gfortran.dg/class_53.f90
^ permalink raw reply [flat|nested] 18+ messages in thread