[Bug fortran/52111] New: [OOP] procedure pointer with polymorphic passed dummy argument

[Bug fortran/52111] New: [OOP] procedure pointer with polymorphic passed dummy argument

[nagl46 at web dot de]

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

             Bug #: 52111
           Summary: [OOP] procedure pointer with polymorphic passed dummy
                    argument
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: nagl46@web.de


I declare a procedure pointer in an abstract type
>> procedure(solve_gen), pointer :: solve

with procedure interface
>> abstract interface
>>   subroutine solve_gen(this, val)
>>     import :: solverAbstract_t
>>     class(solverAbstract_t), intent(inout) :: this
>>     integer, intent(inout) :: val
>>   end subroutine
>> end interface

Class solver_t is a subclass of solverAbstract_t.
Now I want solve to point to
>>  subroutine solveLeft_sub(this, val)
>>    class(solver_t), intent(inout) :: this
>>    integer, intent(inout) :: val
>>
>>    write(*,*) 'i solve left'
>>  end subroutine

Compiling my program with this classes fails with:
>>tatanka@tippi:~/tmp$ gfortran  main.f90
>>main.f90:66.22:
>>
>>        this%solve => solveLeft_sub
>>                      1
>>Error: Interface mismatch in procedure pointer assignment at (1): Type/rank >>mismatch in argument 'this'
>>main.f90:68.22:
>>
>>        this%solve => solveRight_sub
>>                      1
>>Error: Interface mismatch in procedure pointer assignment at (1): Type/rank >>mismatch in argument 'this'
>>main.f90:74.6:
>>
>>  use m_solver
>>      1
>>Fatal Error: Can't open module file 'm_solver.mod' for reading at (1): No such >>file or directory

I found this bug in:
>>GNU Fortran (GCC) 4.7.0 20120131 (experimental)
and in
>>GNU Fortran (GCC) 4.7.0 20120120 (experimental).

In
>>GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
program works fine.
I also tested the bug on cray with
>>hpcatism@eslogin002:~> ftn --version
>>/opt/cray/xt-asyncpe/5.06/bin/ftn: INFO: Compiling with >>CRAYPE_COMPILE_TARGET=native.
>>/opt/cray/cce/8.0.1/cftn/x86-64/bin/ftn_driver.exe: invalid option -- '-'
On cray program also compiled fine and program works.

[Bug fortran/52111] [OOP] procedure pointer with polymorphic passed dummy argument

[nagl46 at web dot de]

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

--- Comment #1 from alexander tismer <nagl46 at web dot de> 2012-02-03 16:22:36 UTC ---
Created attachment 26564
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26564
program that produces compiler error

[Bug fortran/52111] [OOP] procedure pointer with polymorphic passed dummy argument

[burnus at gcc dot gnu.org]

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.

[Bug fortran/52111] [OOP] procedure pointer with polymorphic passed dummy argument

[nagl46 at web dot de]

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

--- Comment #3 from alexander tismer <nagl46 at web dot de> 2012-02-03 17:51:51 UTC ---
Thanks for your annotations.
I will give thought to that.

[Bug fortran/52111] [OOP] procedure pointer with polymorphic passed dummy argument

[nagl46 at web dot de]

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

--- Comment #4 from alexander tismer <nagl46 at web dot de> 2012-02-04 11:02:55 UTC ---
I think you are right. Thanks again for your helpful annotations.

But I'm not sure if I understand everything correctly.

>> Thus, the compiler is not required to diagnose it - and, seemingly, 
>> the Cray compiler doesn't.

I think I understand this statement. And if I change my code like this:

>>  type(solver_t), target :: solverTarget
>>  integer :: val
>>  class(solverAbstract_t), pointer :: solver
>>
>>  solver => solverTarget
>>
>>  call solver%setPrec('l')
>>  call solver%solve(val)

Then I think program should fail because solveLeft_sub is called with
class(solverAbstract_t) as passed dummy argument. This is not conform with the
subroutine. 
In any case gfortran is right, but compiling my new program with Cray there is
no error. And as you mentionend this is ok, because argument checking is not
necessary. But is it correct that program execution is not stopped by an error?
In my opinion at runtime there is the above mentioned problem.

[Bug fortran/52111] [OOP] procedure pointer with polymorphic passed dummy argument

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-05 16:43:38 UTC ---
(In reply to comment #4)
> >> Thus, the compiler is not required to diagnose it - and, seemingly, 
> >> the Cray compiler doesn't.

Regarding the first part of the sentence, the Fortran standard (here: Fortran
2008) has in "1.5 Conformance":

"A processor conforms to this part of ISO/IEC 1539 if: [...]
 (3) it contains the capability to detect and report the use within a submitted
program unit of an additional form or relationship that is not permitted by the
numbered syntax rules or constraints, including the deleted features described
in Annex B"

Thus, for those the standard requires the compiler ("processor") to diagnose
invalid programs (at compile time).


However, it is often not possible to detect invalid code at compile time - or
either not reliably or not in all cases. Thus, the standard does not require
the diagnoses in general - and also not in this case.

How much a compiler checks is a matter of quality of implementation - and
settings. With -Wall or/and -std=f2008 or/and -pedantic, one increases the
change that issues are reported, but ­- with warnings - one get also a lot of
output for perfectly valid code.



> I think I understand this statement. And if I change my code like this:
[...]
> Then I think program should fail because solveLeft_sub is called with
> class(solverAbstract_t) as passed dummy argument. This is not conform with the
> subroutine. 
> In any case gfortran is right, but compiling my new program with Cray there is
> no error. And as you mentionend this is ok, because argument checking is not
> necessary.
> But is it correct that program execution is not stopped by an error?
> In my opinion at runtime there is the above mentioned problem.


There is a problem, however, if one does not access an nonexisting component of
the array or a nonexisting type-bound procedures, one usually gets away with
it. If not, one gets wrong results or a the compiler crashes.

By default compilers do only minimal checking, restricted to the cases where
the standard requires some checking (e.g. allocating an already allocated
variables gives an error). The reason is that most people have somewhat correct
programs and want to run them fast.


Compilers do offer some additional run-time checking (e.g. gfortran's
-fcheck=all), but they can cost quite a bit of performance and they only check
a small subset of potential issues: Those which are commonly to be encountered
and which are somewhat simple to implement.

For your pointer issue, that's not the case: In principle, one should first
check whether the address of the proc-pointer points to a procedure of the
program (and not to a random memory address), then one had to check the
characteristics of the arguments. That's the rank, data type, attributes etc.
And for the type check one had to check whether the dynamic type is compatible
with the actual argument or the declared interface.

Well, doing so is rather difficult. I only know of one compiler which does
(optionally!) extensive checks - and I don't know whether it would detect this
issue.

It is much easier to detect this issue at compile time - that's probably why
the standard is written as it is. But even at compile time it can get
difficult: If one of the arguments in the proc-pointer interface is itself a
procedure interface, which takes again a procedure. One then needs to drill
deeper and deeper into the interface to check whether it correct. -- I am sure,
that it is possible to find cases where also gfortran fails to detect invalid
arguments.


For a compiler writer, it is already difficult enough to generate fast code
from valid programs. Providing an extensive and helpful diagnostic for invalid
code is even more difficult as there are even more ways to write invalid
programs than to write valid programs.


Closed as INVALID.