User account creation filtered due to spam.

Bug 44696 - [OOP] ASSOCIATED fails on polymorphic variables
Summary: [OOP] ASSOCIATED fails on polymorphic variables
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2010-06-28 14:32 UTC by Hans-Werner Boschmann
Modified: 2016-11-16 13:31 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.5.1, 4.6.0
Last reconfirmed: 2010-06-28 20:02:43


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Werner Boschmann 2010-06-28 14:32:08 UTC
program rte1
  implicit none
  type::node_type
     class(node_type),pointer::parent,child
     integer::id
  end type node_type
  type(node_type),target::root
  allocate(root%child)
  root%child%parent=>root
  root%id=1
  root%child%id=2
  print *,root%child%id," is child of ",root%id,":"
  print *,root%child%parent%id,root%id,associated(root%child%parent,root)
  call check(root%child,root)
contains
    subroutine check(this,that)
    class(node_type),intent(in),target :: this
    class(node_type),intent(in),target :: that
    print *,this%id," is child of ",that%id,":"
    print *,this%parent%id,that%id,associated(this%parent,that)
    end subroutine check
end program rte1

------

This is two times the same code: inside the program and as subroutine. The result (GNU Fortran (GCC) 4.6.0 20100627) is different:

           2  is child of            1 :
           1           1 T
           2  is child of            1 :
           1           1 F
Comment 1 Tobias Burnus 2010-06-28 14:42:05 UTC
Confirmed. For the record: Works with the NAG, Intel, and Cray compiler.
Comment 2 janus 2010-06-28 19:35:25 UTC
-fdump-tree-original shows that the ASSOCIATED statement inside the subroutine does not do the right thing:

      D.1556 = this->$data->parent.$data == (struct class$node_type *) that && this->$data->parent.$data != 0B;


"that" should be "that->$data".
Comment 3 janus 2010-06-28 19:46:13 UTC
The following variant also fails (without the ASSOCIATED statement being inside a subroutine):

program rte1
  implicit none
  type::node_type
     class(node_type),pointer::parent,child
     integer::id
  end type node_type
  class(node_type),pointer::root
  allocate(root)
  allocate(root%child)
  root%child%parent=>root
  root%id=1
  root%child%id=2
  print *,root%child%id," is child of ",root%id,":"
  print *,root%child%parent%id,root%id,associated(root%child%parent,root)
end program rte1
Comment 4 janus 2010-06-28 20:02:43 UTC
The fix for this bug turns out to be totally trivial:

Index: gcc/fortran/trans-intrinsic.c
===================================================================
--- gcc/fortran/trans-intrinsic.c       (revision 161504)
+++ gcc/fortran/trans-intrinsic.c       (working copy)
@@ -4416,6 +4416,8 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
   else
     {
       /* An optional target.  */
+      if (arg2->expr->ts.type == BT_CLASS)
+       gfc_add_component_ref (arg2->expr, "$data");
       ss2 = gfc_walk_expr (arg2->expr);
 
       nonzero_charlen = NULL_TREE;


The first argument of ASSOCIATED being polymorphic was already handled correctly, but not so for the second one.
Comment 5 janus 2010-06-29 19:06:25 UTC
Subject: Bug 44696

Author: janus
Date: Tue Jun 29 19:06:07 2010
New Revision: 161554

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161554
Log:
2010-06-29  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/44696
	* trans-intrinsic.c (gfc_conv_associated): Handle polymorphic variables
	passed as second argument of ASSOCIATED.

2010-06-29  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/44696
	* gfortran.dg/associated_target_4.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/associated_target_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog

Comment 6 janus 2010-06-29 19:08:26 UTC
Fixed with r161554. Closing.