Bug 55199 - [OOP] Equivalenced variable has wrong type when used with generic member function
[OOP] Equivalenced variable has wrong type when used with generic member func...
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.7.3
: P3 normal
: ---
Assigned To: janus
: rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-04 02:38 UTC by Rich Townsend
Modified: 2012-11-04 18:01 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-11-04 00:00:00


Attachments
Test program to reproduce the error (769 bytes, text/x-fortran)
2012-11-04 02:38 UTC, Rich Townsend
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2012-11-04 02:38:27 UTC
Created attachment 28606 [details]
Test program to reproduce the error

The attached program fails to compile, with the following error:

assoc_err.f90:49.8:

    a = a + b
        1
Error: Operands of binary numeric operator '+' at (1) are REAL(4)/TYPE(foo_t)

However, the equivalence statement has b => f%func(1.), which has a type of REAL(4) and not TYPE(foo_t).

The problem goes away if I replace the generic function reference with a specific one: b => f%func_1(1.)
Comment 1 janus 2012-11-04 11:11:42 UTC
(In reply to comment #0)
> The attached program fails to compile, with the following error:
> 
> assoc_err.f90:49.8:
> 
>     a = a + b
>         1
> Error: Operands of binary numeric operator '+' at (1) are REAL(4)/TYPE(foo_t)

I can confirm this error with 4.6, 4.7 and trunk. Prior to 4.6 ASSOCIATE was not supported.
Comment 2 janus 2012-11-04 11:23:28 UTC
Further compactified version of the test case:

module assoc_err_m
  implicit none
  type :: foo_t
   contains
     procedure :: func_1
     generic   :: func => func_1
  end type
contains
  real function func_1 (this)
    class(foo_t), intent(in) :: this
  end function
end module

program assoc_err
  use assoc_err_m
  implicit none
  type(foo_t) :: f
  associate(b => f%func())
    print *, 1. + b
  end associate
end program
Comment 3 janus 2012-11-04 12:43:31 UTC
Draft patch:


Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 193047)
+++ gcc/fortran/parse.c	(working copy)
@@ -3394,13 +3394,6 @@ parse_associate (void)
       sym->assoc = a;
       sym->declared_at = a->where;
       gfc_set_sym_referenced (sym);
-
-      /* Initialize the typespec.  It is not available in all cases,
-	 however, as it may only be set on the target during resolution.
-	 Still, sometimes it helps to have it right now -- especially
-	 for parsing component references on the associate-name
-	 in case of association to a derived-type.  */
-      sym->ts = a->target->ts;
     }
 
   accept_statement (ST_ASSOCIATE);


regtesting now ...
Comment 4 janus 2012-11-04 13:40:16 UTC
(In reply to comment #3)
> regtesting now ...

Somewhat expected, this fails on:

FAIL: gfortran.dg/associate_1.f03  -O0  (test for excess errors)
FAIL: gfortran.dg/associate_10.f90  -O  (test for excess errors)



> gfortran-4.8 -cpp associate_1.f03 
associate_1.f03:79.10:

    IF (x%comp /= 1) CALL abort ()
          1
Error: Symbol 'x' at (1) has no IMPLICIT type
associate_1.f03:82.10:

    IF (x%comp /= 5) CALL abort ()
          1
Error: Symbol 'x' at (1) has no IMPLICIT type



> gfortran-4.8 associate_10.f90 
associate_10.f90:19.12:

      x1(1)%i = 1
            1
Error: Symbol 'x1' at (1) has no IMPLICIT type
associate_10.f90:21.12:

      y1(1)%i = 2
            1
Error: Symbol 'y1' at (1) has no IMPLICIT type
Comment 5 janus 2012-11-04 13:56:03 UTC
Here is an improved patch, which hopefully should be free of testsuite regressions (will re-check):

Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 193133)
+++ gcc/fortran/parse.c	(working copy)
@@ -3395,12 +3395,10 @@ parse_associate (void)
       sym->declared_at = a->where;
       gfc_set_sym_referenced (sym);
 
-      /* Initialize the typespec.  It is not available in all cases,
-	 however, as it may only be set on the target during resolution.
-	 Still, sometimes it helps to have it right now -- especially
-	 for parsing component references on the associate-name
-	 in case of association to a derived-type.  */
-      sym->ts = a->target->ts;
+      /* For variables, we can already set the typespec. Other cases have to
+	 wait until resolution stage.  */
+      if (a->target->expr_type == EXPR_VARIABLE)
+	sym->ts = a->target->ts;
     }
 
   accept_statement (ST_ASSOCIATE);
Comment 6 janus 2012-11-04 15:46:38 UTC
(In reply to comment #5)
> Here is an improved patch, which hopefully should be free of testsuite
> regressions (will re-check):

It is. However, I think there is a better way to fix this:


Index: gcc/fortran/primary.c
===================================================================
--- gcc/fortran/primary.c	(revision 193133)
+++ gcc/fortran/primary.c	(working copy)
@@ -1975,6 +1975,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
 	  gcc_assert (primary->symtree->n.sym->attr.referenced);
 	  if (tbp_sym)
 	    primary->ts = tbp_sym->ts;
+	  else
+	    gfc_clear_ts (&primary->ts);
 
 	  m = gfc_match_actual_arglist (tbp->n.tb->subroutine,
 					&primary->value.compcall.actual);



This prevents the EXPR_COMPCALL from having the wrong typespec is the first place (and resets it to BT_UNKNOWN instead).

I will commit this as obvious after regtesting.
Comment 7 janus 2012-11-04 17:13:22 UTC
Author: janus
Date: Sun Nov  4 17:13:16 2012
New Revision: 193136

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193136
Log:
2012-11-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/55199
	* primary.c (gfc_match_varspec): Clear typespec if it cannot be
	determined at this point.

2012-11-04  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/55199
	* gfortran.dg/associate_12.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/associate_12.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/primary.c
    trunk/gcc/testsuite/ChangeLog
Comment 8 janus 2012-11-04 17:15:25 UTC
Fixed with r193136. Closing.

Thanks for reporting this!
Comment 9 Rich Townsend 2012-11-04 18:01:53 UTC
(In reply to comment #8)
> Fixed with r193136. Closing.
> 
> Thanks for reporting this!

Hey, thanks for fixing it so quickly -- you never cease to amaze me!