Bug 45961 - [4.6 Regression] [OOP] Problem with polymorphic type-bound operators
Summary: [4.6 Regression] [OOP] Problem with polymorphic type-bound operators
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: rejects-valid
Depends on:
Blocks:
 
Reported: 2010-10-10 10:03 UTC by janus
Modified: 2016-11-16 13:40 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-10-10 11:04:50


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2010-10-10 10:03:51 UTC
MODULE DAT_MOD
  TYPE :: DAT
  CONTAINS
    PROCEDURE :: LESS_THAN
    GENERIC :: OPERATOR (.LT.) => LESS_THAN
  END TYPE DAT
CONTAINS
  LOGICAL FUNCTION LESS_THAN(A, B)
    CLASS (DAT), INTENT (IN) :: A, B
    LESS_THAN = .true.
  END FUNCTION LESS_THAN
END MODULE DAT_MOD

PROGRAM TEST
  USE DAT_MOD
  IMPLICIT NONE
  TYPE NODE
    CLASS (DAT), POINTER :: PT
  END TYPE NODE
  TYPE (NODE) :: NDA, NDB
  PRINT *, LST(NDA,NDB)
CONTAINS
  LOGICAL FUNCTION LST(A, B)
    CLASS (NODE), INTENT (IN) :: A, B
    LST = A%PT .LT. B%PT
  END FUNCTION LST
END



$ gfortran-4.6 test.f90
test.f90:21.15:

 PRINT *, LST(NDA,NDB)
              1
Error: Type mismatch in argument 'a' at (1); passed TYPE(node) to CLASS(dat)


This means that for some reason the formal arguments of LST come out
wrongly as CLASS(dat), while they are actually CLASS(node)!?!


Originally reported by Mark Rashid at http://gcc.gnu.org/ml/fortran/2010-10/msg00104.html.
Comment 1 janus 2010-10-10 11:04:50 UTC
Patch:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 165126)
+++ gcc/fortran/resolve.c	(working copy)
@@ -5736,7 +5736,7 @@ resolve_typebound_function (gfc_expr* e)
       /* Use the generic name if it is there.  */
       name = name ? name : e->value.function.esym->name;
       e->symtree = expr->symtree;
-      expr->symtree->n.sym->ts.u.derived = declared;
+      e->ref = gfc_copy_ref (expr->ref);
       gfc_add_component_ref (e, "$vptr");
       gfc_add_component_ref (e, name);
       e->value.function.esym = NULL;
Comment 2 Dominique d'Humieres 2010-10-10 16:33:53 UTC
The patch in comment #1 fixes the pr without regression. Note that the test in http://gcc.gnu.org/ml/fortran/2010-10/msg00104.html gives 'T' at run-time while the reduced tests in comment #0 and in http://gcc.gnu.org/ml/fortran/2010-10/msg00120.html give a "Segmentation fault" at run-time (AFAICT the pointers point to nothing).
Comment 3 janus 2010-10-10 18:17:09 UTC
(In reply to comment #2)
> The patch in comment #1 fixes the pr without regression. Note that the test in
> http://gcc.gnu.org/ml/fortran/2010-10/msg00104.html gives 'T' at run-time

... which I guess is the correct answer :)


> while the reduced tests in comment #0 and in
> http://gcc.gnu.org/ml/fortran/2010-10/msg00120.html give a "Segmentation fault"
> at run-time (AFAICT the pointers point to nothing).

Right. They were just meant to isolate the compile-time failure (without making sense at run time).

Thanks for testing, Dominique! I will commit the patch as obvious soon.
Comment 4 janus 2010-10-10 21:35:13 UTC
Author: janus
Date: Sun Oct 10 21:35:10 2010
New Revision: 165263

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

	PR fortran/45961
	* resolve.c (resolve_typebound_function): Bugfix for type-bound
	operators.

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

	PR fortran/45961
	* gfortran.dg/typebound_operator_6.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/typebound_operator_6.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 5 janus 2010-10-10 21:36:19 UTC
Fixed with r165263. Closing.