http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52111
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-03
17:31:45 UTC ---
I think gfortran correctly rejects your code.
You cannot have a procedure pointer, which takes according to the interface a
CLASS(solverAbstract_t) as first argument - and then associate it to a
procedure which takes only a CLASS(solver_t) as argument.
Assume, I declare a another type "my_t", which also extends solverAbstract_t.
If I now do:
class(solver_t):: this
type(my_t) :: x
this%solve => solveLeft_sub
call this%solve (x, 5)
everything is fine according to the standard: this%solve takes as first
argument CLASS(solverAbstract_t) and TYPE(my_t) is conforming to that. However,
"solveLeft_sub" has a problem because it neither expects a "solverAbstract_t"
nor a "my_t" but only "solver_t" or types which are extending "solver_t".
If one does not want to go back to F77 where one blindly passes arguments as
there is no argument checking, the compiler has to have a chance to detect the
problem. As it cannot do it for the call, it has to do it for the proc-pointer
assignment. Which gfortran does.
Thus, "solveLeft_sub" has to also accept CLASS(solverAbstract_t). It might then
do:
select type (this)
class is (solver_t):
! do something
class default
error stop "should never happen"
end select
>From the Fortran 2008 standard (cf. http://gcc.gnu.org/wiki/GFortranStandards):
"7.2.2.4 Procedure pointer assignment"
"If the pointer object has an explicit interface, its characteristics shall be
the same as the pointer target except that the pointer target may be pure even
if the pointer object is not pure and the pointer target may be an elemental
intrinsic procedure even if the pointer object is not elemental."
And "12.3.2.2 Characteristics of dummy data objects":
"The characteristics of a dummy data object are its type, [...]"
Thus, I think the bug is in your program and not in gfortran. However, if you
can find something in the Fortran standard which states otherwise, I am happy
to reconsider my conclusion.
Note that the characteristics have to be the same is not stated via a
constraint in the standard. Thus, the compiler is not required to diagnose it -
and, seemingly, the Cray compiler doesn't.
