[Bug fortran/42385] New: [OOP] poylmorphic operators do not work

[Bug fortran/42385] New: [OOP] poylmorphic operators do not work

[janus at gcc dot gnu dot org]

Spin-off from PR 42144 (comment #6). As the following code demonstrates,
polymorphic type-bound operators are buggy:


module foo_module
 implicit none
 private
 public :: foo

 type :: foo
 contains
   procedure :: times => times_foo
   procedure :: assign => assign_foo
   generic :: operator(*) => times
   generic :: assignment(=) => assign
 end type

contains

   function times_foo(this,factor) result(product)
     class(foo) ,intent(in) :: this
     class(foo) ,allocatable :: product
     real, intent(in) :: factor
   end function

   subroutine assign_foo(lhs,rhs)
     class(foo) ,intent(inout) :: lhs
     class(foo) ,intent(in) :: rhs
   end subroutine

end module

module bar_module
 use foo_module ,only : foo
 implicit none
 private
 public :: bar

 type ,extends(foo) :: bar
   private
   real :: x=1.
 contains
   procedure :: times => times_bar
   procedure :: assign => assign_bar
 end type

contains
 subroutine assign_bar(lhs,rhs)
   class(bar) ,intent(inout) :: lhs
   class(foo) ,intent(in) :: rhs
   select type(rhs)
     type is (bar)
       lhs%x = rhs%x
   end select
 end subroutine
 function times_bar(this,factor) result(product)
   class(bar) ,intent(in) :: this
   real, intent(in) :: factor
   class(foo), allocatable :: product
   select type(this)
     type is (bar)
       allocate(product,source=this)
       select type(product)
         type is(bar)
           product%x = this%x*factor
       end select
   end select
 end function
end module

program main
 use foo_module ,only : foo
 use bar_module ,only : bar
 implicit none
 type(bar) :: unit
 call rescale(unit,3.141592654)
contains
 subroutine rescale(this,scale)
   class(foo) ,intent(inout) :: this
   real, intent(in) :: scale
   this = this*scale
 end subroutine
end program


This test case is compiled flawlessly, but the generated code is wrong:

rescale (struct .class.foo & restrict this, real(kind=4) & restrict scale)
{
  {
    struct .class.foo.a D.1631;

    D.1631 = times_foo ((struct .class.foo *) this, (real(kind=4) *) scale);
    assign_foo ((struct .class.foo *) this, &D.1631);
  }
}

The operators are always resolved to the base-class procedures. Polymorphic
treatment is missing.


-- 
           Summary: [OOP] poylmorphic operators do not work
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janus at gcc dot gnu dot org


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[damian at rouson dot net]

------- Comment #1 from damian at rouson dot net  2010-05-21 14:01 -------
As suggested by Janus and Paul, I'm adding the additional test case below. Note
that the first two pointer assignments in main are not necessary to demonstrate
the linking problem. I put them there (1) to give more detail about what I was
trying to do and (2) because deleting those leaves pointless code since there
would be no reason to do the the third assignment without doing the first two.

$cat link_demo.f03
module field_module
  implicit none

  type ,abstract :: field 
  contains
    procedure(field_eq_field) ,deferred :: assign         
    generic :: assignment(=) => assign
  end type

  abstract interface
    subroutine field_eq_field(lhs,rhs)
      import :: field
      class(field) ,intent(out) :: lhs
      class(field) ,intent(in) :: rhs
    end subroutine
  end interface 
end module
module periodic_field_module
  use field_module ,only : field
  implicit none

  type ,extends(field) :: periodic_field
    real :: f=0.
  contains
    procedure :: assign => copy
  end type

contains
  function new_periodic_field()
    type(periodic_field) ,pointer :: new_periodic_field
    allocate(new_periodic_field)
  end function

  subroutine copy(lhs,rhs)
    class(field) ,intent(in) :: rhs
    class(periodic_field) ,intent(out) :: lhs
    select type(rhs)
      class is (periodic_field)
        lhs%f = rhs%f
      class default
        stop 'periodic_field%copy: unsupported right-hand-side class.'
    end select
  end subroutine
end module
program main
  use field_module 
  use periodic_field_module 
  implicit none
  class(field) ,pointer :: u,f
  u => new_periodic_field() 
  f => new_periodic_field()
  f = u
end program

$ gfortran link_demo.f03 
Undefined symbols:
  "_field_eq_field_", referenced from:
      _MAIN__ in ccFO42I9.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[sfilippone at uniroma2 dot it]

------- Comment #3 from sfilippone at uniroma2 dot it  2010-07-12 14:59 -------
Created an attachment (id=21184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21184&action=view)
additional test-case


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[sfilippone at uniroma2 dot it]

------- Comment #2 from sfilippone at uniroma2 dot it  2010-07-12 14:58 -------
(In reply to comment #1)
Hi Damian,
This is related to the original test case for PR 43945; that test case is now
going to handle the dynamic side of it, but the problem with generics exists
with normal typebound procedures as well. It seems to be related to the
binding_name => specific_name thing, operators are not really relevant. 


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-07-13 09:17 -------
Carry on the test case from PR 43945 comment 19 (cf. also PR 43945 comment 30,
31, 32):

Salvatore wrote:
> Yup, but after discussion with Janus, it seems the failing part is not
> dynamic dispatching, but compile-time resolution. Accordingly, I have
> appended the test case to PR 42385.

As the test case in comment 3 (attachment 21184) is different from the one of
PR 43945 comment 19, I add the latter as well:

Attachment 20927  compiles with both crayftn and gfortran, but the run-time
result is different; while crayftn has

 Allocated COO succesfully, should now set components
 STOP

with gfortran the result is

 Error: Missing ovverriding impl for allocate in class COO


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[sfilippone at uniroma2 dot it]

------- Comment #5 from sfilippone at uniroma2 dot it  2010-07-13 09:24 -------
(In reply to comment #4)
> Carry on the test case from PR 43945 comment 19 (cf. also PR 43945 comment 30,
> 31, 32):
> 
> 
> As the test case in comment 3 (attachment 21184 [edit]) is different from the one of
> PR 43945 comment 19, I add the latter as well:
> 
> Attachment 20927 [edit]  compiles with both crayftn and gfortran, but the run-time
> result is different; while crayftn has
> 
>  Allocated COO succesfully, should now set components
>  STOP
> 
> with gfortran the result is
> 
>  Error: Missing ovverriding impl for allocate in class COO
> 

The two are intended to generate the same error, i.e. resolution to the base
specific instead of the overriding one. As far as I can tell the error is
caused by having a binding-name => specific-name in the base version; if the
base version has just a name (thus binding==specific) the resolution mechanism
works.

Salvatore 


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2010-07-14 21:43 -------
The test cases in comment 3 (attachment 21184) and comment 4 (attachment 20927)
are now tracked in PR 44936 - and fixed by the draft patch there.

The original test case (comment 0) still generates wrong code and the test from
comment 1 still does compile.


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2010-07-16 13:20 -------
Created an attachment (id=21221)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21221&action=view)
Fix for the PR

Please note that this patch contains part of Janus' clean-up of vtabs diff. 
This came about because the tree on my laptop is too old.

I will separate out the fix for PR42385 tonight.

It bootstraps and regtests on RHEL5.3/i686.

Paul

The following runs correctly:
module foo_module
 implicit none
 private
 public :: foo

 type :: foo
   integer :: i
 contains
   procedure :: times => times_foo
   procedure :: assign => assign_foo
   generic :: operator(*) => times
   generic :: assignment(=) => assign
 end type

contains

   function times_foo(this,factor) result(product)
     class(foo) ,intent(in) :: this
     class(foo) ,pointer :: product
     real, intent(in) :: factor
     allocate (product, source = this)
     product%i = this%i * int (factor)
   end function

   subroutine assign_foo(lhs,rhs)
     class(foo) ,intent(inout) :: lhs
     class(foo) ,intent(in) :: rhs
     lhs%i = rhs%i
    end subroutine

end module

module bar_module
 use foo_module ,only : foo
 implicit none
 private
 public :: bar

 type ,extends(foo) :: bar
   real :: x
 contains
   procedure :: times => times_bar
   procedure :: assign => assign_bar
 end type

contains
 subroutine assign_bar(lhs,rhs)
   class(bar) ,intent(inout) :: lhs
   class(foo) ,intent(in) :: rhs
   lhs%i = rhs%i
   select type(rhs)
     type is (bar)
       lhs%x = rhs%x
   end select
 end subroutine
 function times_bar(this,factor) result(product)
   class(bar) ,intent(in) :: this
   real, intent(in) :: factor
   class(foo), pointer :: product
   select type(this)
     type is (bar)
       allocate(product,source=this)
       select type(product)
         type is(bar)
           product%i = this%i*int(factor)
           product%x = this%x*factor
       end select
   end select
 end function
end module

program main
 use foo_module ,only : foo
 use bar_module ,only : bar
 implicit none
 type(foo) :: uniti = foo(2) 
 type(bar) :: unitx = bar(2, 1.0)
 call rescale(uniti, 3.141592654)
 call rescale(unitx, 3.141592654)
 print *, uniti%i
 print *, unitx%x, unitx%i
contains
 subroutine rescale(this,scale)
   class(foo) ,intent(inout) :: this
   real, intent(in) :: scale
   this = this*scale
 end subroutine
end program


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[pault at gcc dot gnu dot org]

------- Comment #8 from pault at gcc dot gnu dot org  2010-07-19 18:49 -------
Subject: Bug 42385

Author: pault
Date: Mon Jul 19 18:48:44 2010
New Revision: 162313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162313
Log:
2010-07-19  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42385
        * interface.c (matching_typebound_op): Add argument for the
        return of the generic name for the procedure.
        (build_compcall_for_operator): Add an argument for the generic
        name of an operator procedure and supply it to the expression.
        (gfc_extend_expr, gfc_extend_assign): Use the generic name in
        calls to the above procedures.
        * resolve.c (resolve_typebound_function): Catch procedure
        component calls for CLASS objects, check that the vtable is
        complete and insert the $vptr and procedure components, to make
        the call.
        (resolve_typebound_function): The same.
        * trans-decl.c (gfc_trans_deferred_vars): Do not deallocate
        an allocatable scalar if it is a result.


2010-07-19  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42385
        * gfortran.dg/class_defined_operator_1.f03 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_defined_operator_1.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[paul dot richard dot thomas at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]



------- Comment #9 from paul dot richard dot thomas at gmail dot com  2010-07-19 20:12 -------
Subject: Re:  [OOP] poylmorphic operators do not work

Fixed on trunk

Paul

> Author: pault
> Date: Mon Jul 19 18:48:44 2010
> New Revision: 162313
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162313
> Log:
> 2010-07-19  Paul Thomas  <pault@gcc.gnu.org>
>
>        PR fortran/42385
>        * interface.c (matching_typebound_op): Add argument for the
>        return of the generic name for the procedure.
>        (build_compcall_for_operator): Add an argument for the generic
>        name of an operator procedure and supply it to the expression.
>        (gfc_extend_expr, gfc_extend_assign): Use the generic name in
>        calls to the above procedures.
>        * resolve.c (resolve_typebound_function): Catch procedure
>        component calls for CLASS objects, check that the vtable is
>        complete and insert the $vptr and procedure components, to make
>        the call.
>        (resolve_typebound_function): The same.
>        * trans-decl.c (gfc_trans_deferred_vars): Do not deallocate
>        an allocatable scalar if it is a result.
>
>
> 2010-07-19  Paul Thomas  <pault@gcc.gnu.org>
>
>        PR fortran/42385
>        * gfortran.dg/class_defined_operator_1.f03 : New test.


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-07-20 08:09 -------
(In reply to comment #9)
> Fixed on trunk

Really close as FIXED. Thanks for the patch.


-- 

burnus at gcc dot gnu dot org changed:

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


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