[Bug fortran/46897] New: [OOP] Polymorphic type - defined ASSIGNMENT(=) not used

[Bug fortran/46897] New: [OOP] Polymorphic type - defined ASSIGNMENT(=) not used

[burnus at gcc dot gnu.org]

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

           Summary: [OOP] Polymorphic type - defined ASSIGNMENT(=) not
                    used
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org


Reported by Damian at http://gcc.gnu.org/ml/fortran/2010-12/msg00063.html

The following program should print "defined assignment called". It does so with
the IBM compiler but not with gfortran.

module component_parent_child_module
  implicit none
  type component
  contains
    procedure :: assign
    generic :: assignment(=)=>assign
  end type
  type parent
    type(component) :: foo
  end type
  type, extends(parent) :: child
  end type
contains
  subroutine assign(lhs,rhs)
    class(component), intent(out) :: lhs
    class(component), intent(in) :: rhs
    print *,'defined assignment called'
  end subroutine 
  type(child) function new_child()
  end function
end module 

program main
  use component_parent_child_module
  implicit none
  type(child) :: infant
  infant = new_child()
end

[Bug fortran/46897] [OOP] Polymorphic type - defined ASSIGNMENT(=) not used

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2010-12-12 22:15:30 UTC ---
Here is a slightly reduced test case:


module m
  implicit none

  type component
  contains
    procedure :: assign
    generic :: assignment(=)=>assign
  end type

  type t
    type(component) :: foo
  end type

contains

  subroutine assign(lhs,rhs)
    class(component), intent(out) :: lhs
    class(component), intent(in) :: rhs
    print *,'defined assignment called'
  end subroutine

end module 

program main
  use m
  implicit none
  type(t) :: infant, newchild
  infant = newchild
end

[Bug fortran/46897] defined ASSIGNMENT(=) not used for derived type component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[OOP] Polymorphic type -    |defined ASSIGNMENT(=) not
                   |defined ASSIGNMENT(=) not   |used for derived type
                   |used                        |component

--- Comment #2 from janus at gcc dot gnu.org 2010-12-12 22:25:52 UTC ---
I think one can run into the same problem already without polymorphism:


module m
  implicit none

  type component
  end type

  interface assignment(=)
    module procedure assign
  end interface

  type t
    type(component) :: foo
  end type

contains

  subroutine assign(lhs,rhs)
    type(component), intent(out) :: lhs
    type(component), intent(in) :: rhs
    print *,'defined assignment called'
  end subroutine

end module 

program main
  use m
  implicit none
  type(t) :: infant, newchild
  infant = newchild
end

[Bug fortran/46897] defined ASSIGNMENT(=) not used for derived type component

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-13 07:37:47 UTC ---
Actually, I am less and less sure that this is a wrong-code issue. For

  type(t) :: infant, newchild
  infant = newchild

one has the type "T" but the defined assignment is for "component". If one
compiles the program in comment 2, none of my compilers uses the defined
assignment.

(When reading the program first, I somehow read that the defined assignment it
for "t" and not for "component". I will later re-read the F2008 standard.)

[Bug fortran/46897] defined ASSIGNMENT(=) not used for derived type component

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2010-12-13 09:07:43 UTC ---
(In reply to comment #3)
> Actually, I am less and less sure that this is a wrong-code issue.

I'm also a bit skeptical that this really is a bug. One should check the
standard.


> For
> 
>   type(t) :: infant, newchild
>   infant = newchild
> 
> one has the type "T" but the defined assignment is for "component". If one
> compiles the program in comment 2, none of my compilers uses the defined
> assignment.

Not even IBM?

If one doesn't use the defined assignment in comment #2, I don't see why one
should do so in comment #0.

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.13 09:28:27
            Summary|defined ASSIGNMENT(=) not   |[OOP] type-bound defined
                   |used for derived type       |ASSIGNMENT(=) not used for
                   |component                   |derived type component in
                   |                            |intrinsic assign
     Ever Confirmed|0                           |1

--- Comment #5 from janus at gcc dot gnu.org 2010-12-13 09:28:27 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Actually, I am less and less sure that this is a wrong-code issue.
> 
> I'm also a bit skeptical that this really is a bug. One should check the
> standard.

Ok, I think the relevant part is the following quote from chapter 7.2.1.3 of
the F08 standard (line 13):

"An intrinsic assignment where the variable is of derived type is performed as
if each component of the variable were assigned from the corresponding
component of expr using pointer assignment (7.2.2) for each pointer component,
defined assignment for each nonpointer nonallocatable component of a type that
has a type-bound defined assignment consistent with the component, intrinsic
assignment for each other nonpointer nonallocatable component, ..."

Note that this mentions only *type-bound* defined assignment, which means in
fact that the defined assignment should only be used in comment #0 and #1, but
not in comment #2 (since it is not type-bound there).

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[damian at rouson dot net]

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

--- Comment #6 from Damian Rouson <damian at rouson dot net> 2010-12-13 15:16:42 UTC ---
Janus, 

Thanks for finding the relevant language in the standard.  

In case it helps, what I submitted originally was a reduced example of code
written by Jim Xia, who is member of both the IBM compiler test team and the
Fortran standards committee.  IBM XL Fortran 13.1 calls the defined assignment
in my original example (and interestingly in Janus's reduced example, although
it appears from what you wrote that it is not required to do so in your reduced
example).  

Unfortunately, Jim is on vacation, so I probably won't be able to find out soon
what part of the standard he was relying upon when he wrote the relevant code,
but I know he gave it a a lot of thought becasue that code plays a central role
in an algorithm that he developed with us for the open-source ForTrilinos
package (http://trilinos.sandia.gov/download/trilinos-10.6.html).  Every
derived type in ForTrilinos extends a derived type analogous to the "parent"
type in my original posting.  The defined assignment is needed for a reference
counting scheme to prevent memory management problems.  If the compiler does
not call the defined assignment, it would have significant downstream
implications for all ForTrilinos derived types and for all user-defined types
that aggregate or extend ForTrilinos derived types.

Damian

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-13 16:36:57 UTC ---
Richard Maine agrees with the assessment of comment 5:

- For INTERFACE-defined defined-ASSIGNMENT(=), the intrinsic assignment
  should be used (cf. example in comment 2) - correctly handled by gfortran

- For type-bound-defined defined-assignment, the defined assignment should be
  used (comment 0 and comment 1). gfortran currently mishandles this
  F2003 feature.

Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d6220bd4aa90f368

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |pault at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> 2012-08-11 13:18:01 UTC ---
Created attachment 27990
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27990
An almost fix for the PR

This takes the last wrinkles out of the version that Alessandro and I last
worked on.

The final step is to add the code for pointer components and to prepare the
testcases.

Cheers

Paul

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> 2012-12-01 08:00:32 UTC ---
Author: pault
Date: Sat Dec  1 08:00:22 2012
New Revision: 194016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194016
Log:
2012-12-01   Alessandro Fanfarillo <alessandro.fanfarillo@gmail.com>
             Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/46897
    * gfortran.h : Add bit field 'defined_assign_comp' to
    symbol_attribute structure.
    Add primitive for gfc_add_full_array_ref.
    * expr.c (gfc_add_full_array_ref): New function.
    (gfc_lval_expr_from_sym): Call new function.
    * resolve.c (add_comp_ref): New function.
    (build_assignment): New function.
    (get_temp_from_expr): New function
    (add_code_to_chain): New function
    (generate_component_assignments): New function that calls all
    the above new functions.
    (resolve_code): Call generate_component_assignments.
    (check_defined_assignments): New function.
    (resolve_fl_derived0): Call check_defined_assignments.
    (gfc_resolve): Reset component_assignment_level in case it is
    left in a bad state by errors.


    * resolve.c (is_sym_host_assoc, resolve_procedure_interface,
    resolve_contained_fntype, resolve_procedure_expression,
    resolve_elemental_actual, resolve_global_procedure,
    is_scalar_expr_ptr, gfc_iso_c_func_interface, resolve_function,
    set_name_and_label, gfc_iso_c_sub_interface,
    resolve_specific_s0, resolve_operator, compare_bound_mpz_t,
    gfc_resolve_character_operator, resolve_typebound_function,
    gfc_resolve_expr, forall_index, remove_last_array_ref,
    conformable_arrays, resolve_allocate_expr,
    resolve_allocate_deallocate, resolve_select_type,
    resolve_transfer, resolve_where,
    gfc_resolve_where_code_in_forall, gfc_resolve_forall_body,
    gfc_count_forall_iterators, resolve_values,
    resolve_bind_c_comms, resolve_bind_c_derived_types,
    gfc_verify_binding_labels, apply_default_init,
    build_default_init_expr, apply_default_init_local,
    resolve_fl_var_and_proc, resolve_fl_procedure,
    gfc_resolve_finalizers, check_generic_tbp_ambiguity,
    resolve_typebound_intrinsic_op, resolve_typebound_procedure,
    resolve_typebound_procedures, ensure_not_abstract,
    resolve_fl_derived0, resolve_fl_parameter, resolve_symbol,
    resolve_equivalence_derived): Remove trailing white space.
    * gfortran.h : Remove trailing white space.

2012-12-01   Alessandro Fanfarillo <alessandro.fanfarillo@gmail.com>
             Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/46897
    * gfortran.dg/defined_assignment_1.f90: New test.
    * gfortran.dg/defined_assignment_2.f90: New test.
    * gfortran.dg/defined_assignment_3.f90: New test.
    * gfortran.dg/defined_assignment_4.f90: New test.
    * gfortran.dg/defined_assignment_5.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_1.f90
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_2.f90
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_3.f90
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_4.f90
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-03 10:02:05 UTC ---
The patch of comment 9 fixes most of the issues. However, some are still left.
Cf. http://gcc.gnu.org/ml/fortran/2012-11/msg00072.html

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Draft patch:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
     tmp->n.sym->attr.dimension = 0;

+  gfc_commit_symbol (tmp->n.sym);
   gfc_set_sym_referenced (tmp->n.sym);
   gfc_add_flavor (&tmp->n.sym->attr, FL_VARIABLE, name, NULL);

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #11)
> Draft patch:

That patch should have gone to PR57364. However, it is related as it fixes a
regression caused by a commit for this PR, namely be the one in comment 9.

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #10)
> The patch of comment 9 fixes most of the issues. However, some are still
> left. Cf. http://gcc.gnu.org/ml/fortran/2012-11/msg00072.html

See also PR57696. The not-supported part is currently rejected with:

  if (depth > 1)
    {
      gfc_warning ("TODO: type-bound defined assignment(s) at %L not "
                   "done because multiple part array references would "
                   "occur in intermediate expressions.", &(*code)->loc);
      return;
    }

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[gronki at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897

Dominik Gronkiewicz <gronki at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gronki at gmail dot com

--- Comment #14 from Dominik Gronkiewicz <gronki at gmail dot com> ---
Still affected by this bug in 10.2.1. ifort, in contrast, calls the defined
assignment, which is consistent with the cited paragraph of the standard (point
13 in 10.2.1.3 of F2018 standard draft):

I wanted to file a new bug but found this one so just bumping. :)
Dominik

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[trnka at scm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897

Tomáš Trnka <trnka at scm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trnka at scm dot com

--- Comment #15 from Tomáš Trnka <trnka at scm dot com> ---
(In reply to Dominik Gronkiewicz from comment #14)
> Still affected by this bug in 10.2.1. ifort, in contrast, calls the defined
> assignment, which is consistent with the cited paragraph of the standard
> (point 13 in 10.2.1.3 of F2018 standard draft):
> 
> I wanted to file a new bug but found this one so just bumping. :)
> Dominik

Can you share a testcase that is failing for you? This issue seems to be fixed
for me on GCC 10, so you have probably hit a corner case of some sort.

Is there perhaps an "allocatable" component involved? If so, that's PR57696
which is still unfixed (so defined assignments don't work inside any
allocatable components with GCC but they do with recent enough IFort).