[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2016-11-16 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||rejects-valid

   Last reconfirmed||2012-11-04

 CC||janus at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|Equivalenced variable has   |[OOP] Equivalenced variable

   |wrong type when used with   |has wrong type when used

   |generic member function |with generic member

   ||function



--- Comment #1 from janus at gcc dot gnu.org 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.


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



--- Comment #2 from janus at gcc dot gnu.org 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


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |



--- Comment #3 from janus at gcc dot gnu.org 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 ...


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



--- Comment #4 from janus at gcc dot gnu.org 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


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



--- Comment #5 from janus at gcc dot gnu.org 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);


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



--- Comment #6 from janus at gcc dot gnu.org 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.


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



--- Comment #7 from janus at gcc dot gnu.org 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=gccview=revrev=193136

Log:

2012-11-04  Janus Weil  ja...@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  ja...@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


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread janus at gcc dot gnu.org


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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from janus at gcc dot gnu.org 2012-11-04 17:15:25 UTC ---

Fixed with r193136. Closing.



Thanks for reporting this!


[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

2012-11-04 Thread townsend at astro dot wisc.edu


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



--- Comment #9 from Rich Townsend townsend at astro dot wisc.edu 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!