public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE
@ 2010-12-17 10:34 burnus at gcc dot gnu.org
  2010-12-17 20:44 ` [Bug fortran/46990] " janus at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-17 10:34 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

           Summary: [OOP] gfortran rejects passing a CLASS variable to
                    TYPE
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org


In the following program a polymorphic dummy is passed as actual argument to a
non-polymorphic dummy of the declared type.

The program compiles with the ifort 11.1 and nagf95 5.1, but gfortran rejects
it with:
    call two(x)
             1
Error: Type mismatch in argument 'x' at (1); passed CLASS(t) to TYPE(t)


Both compiler reject passing a CLASS(t2) variable to TYPE(t) or CLASS(t) to
TYPE(t2). (Where "t2" extends type "t".)

 * * *

>From the standard.

"The dummy argument shall be type compatible with the actual argument. If the
actual argument is a polymorphic coindexed object, the dummy argument shall not
be polymorphic." (F2008, 12.5.2.4)

"A nonpolymorphic entity is type compatible only with entities of the same
declared type." (4.3.1.3)

Thus, the dummy argument (a nonpolymorphic entitiy) is type compatible with
entities (i.e. actual actual arguments) of the same declared type.

 * * *

module m
  type t
    integer :: i
  end type t
contains
  subroutine one(x)
    class(t) :: x
    call two(x)
  end subroutine one
  subroutine two(x)
    type(t) :: x
  end subroutine two
end module m


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
@ 2010-12-17 20:44 ` janus at gcc dot gnu.org
  2010-12-17 21:21 ` mikael at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-17 20:44 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.17 20:43:55
     Ever Confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org 2010-12-17 20:43:55 UTC ---
Good point. I was assuming we got the polymorphic type compatibility right by
now, but this case I missed completely.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
  2010-12-17 20:44 ` [Bug fortran/46990] " janus at gcc dot gnu.org
@ 2010-12-17 21:21 ` mikael at gcc dot gnu.org
  2010-12-17 21:37 ` janus at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2010-12-17 21:21 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 2010-12-17 21:21:17 UTC ---
I don't see the point here.
Since one calls two (which expects a type(t)) x in one (of type class(t)) is
forced to be a type(t) entity actually. Why not make it a type(t) then ?


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
  2010-12-17 20:44 ` [Bug fortran/46990] " janus at gcc dot gnu.org
  2010-12-17 21:21 ` mikael at gcc dot gnu.org
@ 2010-12-17 21:37 ` janus at gcc dot gnu.org
  2010-12-17 22:04 ` janus at gcc dot gnu.org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-17 21:37 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #3 from janus at gcc dot gnu.org 2010-12-17 21:37:44 UTC ---
(In reply to comment #2)
> I don't see the point here.
> Since one calls two (which expects a type(t)) x in one (of type class(t)) is
> forced to be a type(t) entity actually. Why not make it a type(t) then ?

Of course this small example does not make very much sense. But in general
there might be situations where it's more useful to pass a CLASS to a TYPE.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2010-12-17 21:37 ` janus at gcc dot gnu.org
@ 2010-12-17 22:04 ` janus at gcc dot gnu.org
  2010-12-18 16:27 ` janus at gcc dot gnu.org
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-17 22:04 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|2010-12-17 20:43:55         |2010.12.17 22:04:35
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from janus at gcc dot gnu.org 2010-12-17 22:04:35 UTC ---
Here is a preliminary patch. Hope I got the logic right ...


Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c    (revision 167977)
+++ gcc/fortran/symbol.c    (working copy)
@@ -4770,21 +4770,24 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typesp
   bool is_class2 = (ts2->type == BT_CLASS);
   bool is_derived1 = (ts1->type == BT_DERIVED);
   bool is_derived2 = (ts2->type == BT_DERIVED);
+  gfc_symbol *t1,*t2;

-  if (!is_derived1 && !is_derived2 && !is_class1 && !is_class2)
+  if (!(is_derived1 || is_class1) || !(is_derived2 || is_class2))
     return (ts1->type == ts2->type);

-  if (is_derived1 && is_derived2)
-    return gfc_compare_derived_types (ts1->u.derived, ts2->u.derived);
+  t1 = ts1->u.derived;
+  t2 = ts2->u.derived;
+  
+  if (is_class2)
+    t2 = t2->components->ts.u.derived;

-  if (is_class1 && is_derived2)
-    return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
-                     ts2->u.derived);
-  else if (is_class1 && is_class2)
-    return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
-                     ts2->u.derived->components->ts.u.derived);
+  if (is_derived1)
+    return gfc_compare_derived_types (t1, t2);
   else
-    return 0;
+    {
+      t1 = t1->components->ts.u.derived;
+      return gfc_type_is_extension_of (t1, t2);
+    }
 }


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2010-12-17 22:04 ` janus at gcc dot gnu.org
@ 2010-12-18 16:27 ` janus at gcc dot gnu.org
  2010-12-18 17:09 ` burnus at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu.org @ 2010-12-18 16:27 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

--- Comment #5 from janus at gcc dot gnu.org 2010-12-18 16:27:10 UTC ---
(In reply to comment #4)
> Here is a preliminary patch. Hope I got the logic right ...

The patch in comment #4 triggers two testsuite failures:

FAIL: gfortran.dg/dummy_procedure_4.f90  -O   (test for errors, line 28)
FAIL: gfortran.dg/proc_ptr_30.f90  -O   (test for errors, line 25)

Both of them come from PR46067. I think they are actually valid Fortran and
it's wrong to expect an error message.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2010-12-18 16:27 ` janus at gcc dot gnu.org
@ 2010-12-18 17:09 ` burnus at gcc dot gnu.org
  2011-02-01  9:27 ` burnus at gcc dot gnu.org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 17:09 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 17:08:49 UTC ---
(In reply to comment #5)
> The patch in comment #4 triggers two testsuite failures:
> 
> FAIL: gfortran.dg/dummy_procedure_4.f90  -O   (test for errors, line 28)
> FAIL: gfortran.dg/proc_ptr_30.f90  -O   (test for errors, line 25)
> 
> Both of them come from PR46067. I think they are actually valid Fortran and
> it's wrong to expect an error message.

I disagree. The first is about passing a procedure to a procedure dummy
argument, the second about associating a procedure with a proc-pointer - both
require that the characteristic is the same:

"7.2.2.4 Procedure pointer assignment"
"If the pointer object has an explicit interface, its characteristics shall be
the same as the pointer target except that the pointer target may be pure even
if the pointer object is not pure and the pointer target may be an elemental
intrinsic procedure even if the pointer object is not elemental. If the
characteristics of the pointer object or the pointer target are such that an
explicit interface is required, both the pointer object and the pointer target
shall have an explicit interface."

"12.5.2.9 Actual arguments associated with dummy procedure entities"
"If the interface of a dummy procedure is explicit, its characteristics as a
procedure (12.3.1) shall be the same as those of its e\vective argument, except
that a pure e\vective argument may be associated with a dummy argument that is
not pure and an elemental intrinsic actual procedure may be associated with a
dummy procedure (which cannot be elemental)."


Compare this with (cf. comment 0): "The dummy argument shall be type compatible
with the actual argument." -- which is less strict.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2010-12-18 17:09 ` burnus at gcc dot gnu.org
@ 2011-02-01  9:27 ` burnus at gcc dot gnu.org
  2011-12-11 20:48 ` pault at gcc dot gnu.org
  2011-12-12  9:03 ` burnus at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-01  9:27 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-01 09:26:52 UTC ---
A variant is
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/dad37643dd8cd0c6

where the defined assignment has:
  elemental subroutine assign (a, b)
    class(base_type), intent(out) :: a
    type(base_type), intent(in) :: b

which is not recognized by gfortran and thus the:
    class(base_type), dimension(:), allocatable, intent(inout) :: a
    class(base_type), dimension(:), allocatable :: tmp 
    tmp(:size(a)) = a             ! polymorphic l.h.s. 

is rejected.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2011-02-01  9:27 ` burnus at gcc dot gnu.org
@ 2011-12-11 20:48 ` pault at gcc dot gnu.org
  2011-12-12  9:03 ` burnus at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2011-12-11 20:48 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> 2011-12-11 20:42:32 UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  <pault@gcc.gnu.org>
    Tobias Burnus  <burnus@gcc.gnu.org>

    PR fortran/41539
    PR fortran/43214
    PR fortran/43969
    PR fortran/44568
    PR fortran/46356
    PR fortran/46990
    PR fortran/49074
    * interface.c(symbol_rank): Return the rank of the _data
    component of class objects.
    (compare_parameter): Also compare the derived type of the class
    _data component for type mismatch.  Similarly, return 1 if the
    formal and _data ranks match.
    (compare_actual_formal): Do not compare storage sizes for class
    expressions. It is an error if an actual class array, passed to
    a formal class array is not full.
    * trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
    gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
    gfc_vtable_extends_get, gfc_vtable_def_init_get,
    gfc_vtable_copy_get): New functions for class API.
    (gfc_conv_derived_to_class): For an array reference in an
    elemental procedure call retain the ss to provide the
    scalarized array reference. Moved in file.
    (gfc_conv_class_to_class): New function.
        (gfc_conv_subref_array_arg): Use the type of the
    class _data component as a basetype.
    (gfc_conv_procedure_call): Ensure that class array expressions
    have both the _data reference and an array reference. Use 
    gfc_conv_class_to_class to handle class arrays for elemental
    functions in scalarized loops, class array elements and full
    class arrays. Use a call to gfc_conv_subref_array_arg in order
    that the copy-in/copy-out for passing class arrays to derived
    type arrays occurs correctly.
    (gfc_conv_expr): If it is missing, add the _data component
    between a class object or component and an array reference.
    (gfc_trans_class_array_init_assign): New function.
    (gfc_trans_class_init_assign): Call it for array expressions.
    * trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
    class scalars since their size will depend on the dynamic type.
    (build_class_array_ref): New function.
    (gfc_conv_scalarized_array_ref): Call build_class_array_ref.
    (gfc_array_init_size): Add extra argument, expr3, that represents
    the SOURCE argument. If present,use this for the element size.
    (gfc_array_allocate): Also add argument expr3 and use it when
    calling gfc_array_init_size.
    (structure_alloc_comps): Enable class arrays.
    * class.c (gfc_add_component_ref): Carry over the derived type
    of the _data component.
    (gfc_add_class_array_ref): New function.
    (class_array_ref_detected): New static function.
    (gfc_is_class_array_ref): New function that calls previous.
    (gfc_is_class_scalar_expr): New function.
    (gfc_build_class_symbol): Throw not implemented error for
    assumed size class arrays.  Remove error that prevents
    CLASS arrays.
    (gfc_build_class_symbol): Prevent pointer/allocatable conflict.
    Also unset codimension.
    (gfc_find_derived_vtab): Make 'copy' elemental and set the
    intent of the arguments accordingly.: 
    * trans-array.h : Update prototype for gfc_array_allocate.
    * array.c (gfc_array_dimen_size): Return failure if class expr.
    (gfc_array_size): Likewise.
    * gfortran.h : New prototypes for gfc_add_class_array_ref,
    gfc_is_class_array_ref and gfc_is_class_scalar_expr.
    * trans-stmt.c (trans_associate_var): Exclude class targets
    from test. Move the allocation of the _vptr to an earlier time
    for class objects.
    (trans_associate_var): Assign the descriptor directly for class
    arrays.
    (gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
    Convert array element references into sections. Do not invoke
    gfc_conv_procedure_call, use gfc_trans_call instead.
    * expr.c (gfc_get_corank): Fix for BT_CLASS.
    (gfc_is_simply_contiguous): Exclude class from test.
    * trans.c (gfc_build_array_ref): Include class array refs.
    * trans.h : Include prototypes for class API functions that are
    new in trans-expr. Define GFC_DECL_CLASS(node).
    * resolve.c (check_typebound_baseobject ): Remove error for
    non-scalar base object.
    (resolve_allocate_expr): Ensure that class _data component is
    present. If array, call gfc_expr_to_intialize.
    (resolve_select): Remove scalar error for SELECT statement as a
    temporary measure.
    (resolve_assoc_var): Update 'target' (aka 'selector') as
    needed. Ensure that the target expression has the right rank.
    (resolve_select_type): Ensure that target expressions have a
    valid locus.
    (resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
    * trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
    appropriate.
    (gfc_trans_deferred_vars): Get class arrays right.
    * match.c(select_type_set_tmp): Add array spec to temporary.
    (gfc_match_select_type): Allow class arrays.
    * check.c (array_check): Ensure that class arrays have refs.
    (dim_corank_check, dim_rank_check): Retrun success if class.
    * primary.c (gfc_match_varspec): Fix for class arrays and
    co-arrays. Make sure that class _data is present.
    (gfc_match_rvalue): Handle class arrays.
    *trans-intrinsic.c (gfc_conv_intrinsic_size): Add class array
    reference.
    (gfc_conv_allocated): Add _data component to class expressions.
    (gfc_add_intrinsic_ss_code): ditto.
    * simplify.c (simplify_cobound): Fix for BT_CLASS.
    (simplify_bound): Return NULL for class arrays.
    (simplify_cobound): Obtain correct array_spec. Use cotype as
    appropriate. Use arrayspec for bounds.

2011-12-11  Paul Thomas  <pault@gcc.gnu.org>
    Tobias Burnus  <burnus@gcc.gnu.org>

    PR fortran/41539
    PR fortran/43214
    PR fortran/43969
    PR fortran/44568
    PR fortran/46356
    PR fortran/46990
    PR fortran/49074
    * gfortran.dg/class_array_1.f03: New.
    * gfortran.dg/class_array_2.f03: New.
    * gfortran.dg/class_array_3.f03: New.
    * gfortran.dg/class_array_4.f03: New.
    * gfortran.dg/class_array_5.f03: New.
    * gfortran.dg/class_array_6.f03: New.
    * gfortran.dg/class_array_7.f03: New.
    * gfortran.dg/class_array_8.f03: New.
    * gfortran.dg/coarray_poly_1.f90: New.
    * gfortran.dg/coarray_poly_2.f90: New.
    * gfortran.dg/coarray/poly_run_1.f90: New.
    * gfortran.dg/coarray/poly_run_2.f90: New.
    * gfortran.dg/class_to_type_1.f03: New.
    * gfortran.dg/type_to_class_1.f03: New.
    * gfortran.dg/typebound_assignment_3.f03: Remove the error.
    * gfortran.dg/auto_dealloc_2.f90: Occurences of __builtin_free
    now 2.
    * gfortran.dg/class_19.f03: Occurences of __builtin_free now 8.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_array_1.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_2.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_3.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_4.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_5.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_6.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_7.f03
    trunk/gcc/testsuite/gfortran.dg/class_array_8.f03
    trunk/gcc/testsuite/gfortran.dg/class_to_type_1.f03
    trunk/gcc/testsuite/gfortran.dg/coarray/poly_run_1.f90
    trunk/gcc/testsuite/gfortran.dg/coarray/poly_run_2.f90
    trunk/gcc/testsuite/gfortran.dg/coarray_poly_1.f90
    trunk/gcc/testsuite/gfortran.dg/coarray_poly_2.f90
    trunk/gcc/testsuite/gfortran.dg/type_to_class_1.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/fortran/check.c
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/simplify.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-array.h
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/auto_dealloc_2.f90
    trunk/gcc/testsuite/gfortran.dg/class_19.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE
  2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
                   ` (7 preceding siblings ...)
  2011-12-11 20:48 ` pault at gcc dot gnu.org
@ 2011-12-12  9:03 ` burnus at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-12-12  9:03 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-12 08:48:20 UTC ---
FIXED on the 4.7 trunk.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2011-12-12  8:49 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-17 10:34 [Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE burnus at gcc dot gnu.org
2010-12-17 20:44 ` [Bug fortran/46990] " janus at gcc dot gnu.org
2010-12-17 21:21 ` mikael at gcc dot gnu.org
2010-12-17 21:37 ` janus at gcc dot gnu.org
2010-12-17 22:04 ` janus at gcc dot gnu.org
2010-12-18 16:27 ` janus at gcc dot gnu.org
2010-12-18 17:09 ` burnus at gcc dot gnu.org
2011-02-01  9:27 ` burnus at gcc dot gnu.org
2011-12-11 20:48 ` pault at gcc dot gnu.org
2011-12-12  9:03 ` burnus at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).