* [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