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.
