[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-20
                 CC|                            |burnus at gcc dot gnu.org
   Target Milestone|---                         |4.6.3
            Summary|bug when submitting a class |[4.6/4.7 Regression][OOP]
                   |pointer to a subroutine     |bug when submitting a class
                   |                            |pointer to a subroutine
     Ever Confirmed|0                           |1

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-20 14:27:04 UTC ---
Conformed. Works with NAG f95 and ifort. And works with GCC 4.5. (Probably
because the valid but not correctly working check was not yet implemented.)


The failing check (in interface.c's compare_parameter; cf. PR46161, Rev.
166018) is:

  /* F2003, 12.5.2.5.  */
  if (formal->ts.type == BT_CLASS
      && (CLASS_DATA (formal)->attr.class_pointer
          || CLASS_DATA (formal)->attr.allocatable))
    {
...
      if (CLASS_DATA (actual)->ts.u.derived
          != CLASS_DATA (formal)->ts.u.derived)
            gfc_error ("Actual argument to '%s' at %L must have the same "
                       "declared type", formal->name, &actual->where);


Thus, the question is why 
  CLASS_DATA (actual)->ts.u.derived ! = CLASS_DATA (formal)->ts.u.derived
or in other words why do we have two different symbols in the symtree? We have:

(gdb) p formal->ts.u.derived->name
$4 = 0x2aaaacf45000 "__class_m_sparsematrix_Sparsematrix_t_p"
(gdb) p actual->ts.u.derived->name
$5 = 0x2aaaacf45000 "__class_m_sparsematrix_Sparsematrix_t_p"


What I find a bit odd is:
(gdb) p formal->ts.u.derived->module
$9 = 0x2aaaace25fc0 ""  ! <<< pointer to empty string
(gdb) p actual->ts.u.derived->module
$8 = 0x0  ! <<< NULL pointer

Otherwise, the two belong (unsurprisingly) to different namespaces:
(gdb) p actual->ts.u.derived->ns->proc_name->name
$13 = 0x2aaaace25fa8 "main"
(gdb) p formal->ts.u.derived->ns->proc_name->name
$14 = 0x2aaaace25fb0 "test"

Thus, having a different symbol - and hence a different pointer address - is
not too surprising.