(j3.2006) Whose bug is it?

[Kurt W Hirchert]

Robert Corbett wrote:
> A user claims that of all the Fortran 95 compilers he has tried,
> and he has a list, only Sun Fortran fails to compile the following
> program:
>
>        MODULE M1
>          INTERFACE SUBR
>            MODULE PROCEDURE SUBR1
>          END INTERFACE
>        CONTAINS
>          SUBROUTINE SUBR1
>          END SUBROUTINE
>        END
>
>        MODULE M2
>          INTERFACE SUBR
>            MODULE PROCEDURE SUBR2
>          END INTERFACE
>        CONTAINS
>          SUBROUTINE SUBR2
>          END SUBROUTINE
>        END
>
>        PROGRAM MAIN
>          USE M1
>          CALL S
>        CONTAINS
>          SUBROUTINE S
>            USE M2
>            CALL SUBR
>          END SUBROUTINE
>        END
>
> Sun Fortran does fail to compile the program.  It gives the error
> message
>
>         USE M1
>              ^
> "test.f", Line = 20, Column = 6: ERROR: The specific interfaces for 
> "SUBR1" and "SUBR2" make the GENERIC interface "SUBR" ambiguous.
>
> The user seems to think that the definition imported by the USE
> statement in the internal subroutine S should override the definition
> imported by the USE statement that appears directly in the main
> program.  I think he is wrong.  Am I overlooking something?
I apologize for the delay in supplying this response:

If you carefully at clause 12.4.4 of 04-007, you will find that your 
user's expectations are correct, although the reasoning behind them may 
not be fully so.  In particular, we find in 12.4.4.1 that the rules from 
16.2.3 about generic ambiguity are applied to specific interfaces 
declared in the scoping unit or made accessible by use association, but 
_not_ to those potentially accessible through host association or an 
INTRINSIC declaration.  The latter are handled by preferences in 
disambiguation.  (This is the generic
equivalent of the rules Craig cited from 16.4.1.3 for nongenerics.)

In this example, we can think of the SUBR2 version of SUBR overriding 
the SUBR1 version, because there is no form of procedure reference not 
accepted by SUBR2 that is accepted by SUBR1.  If we modify the example 
slightly, we can show a partial override:

       MODULE M1
         INTERFACE SUBR
           MODULE PROCEDURE SUBR1
         END INTERFACE
       CONTAINS
         SUBROUTINE SUBR1(K)
           INTEGER K
         END SUBROUTINE
       END

       MODULE M2
         INTERFACE SUBR
           MODULE PROCEDURE SUBR2
         END INTERFACE
       CONTAINS
         SUBROUTINE SUBR2(N)
           INTEGER N
         END SUBROUTINE
       END

       PROGRAM MAIN
         USE M1
         CALL S
       CONTAINS
         SUBROUTINE S
           USE M2
           CALL SUBR(K=3)  ! unambiguously references SUBR1
           CALL SUBR(N=3)  ! unambiguously references SUBR2
           CALL SUBR(3)    ! ambiguous, but references SUBR2 by rules of 12.4.4.1
         END SUBROUTINE
       END


[At this point, I'm certain there will be someone out there that will 
insist I am misreading 12.4.4.  I don't know whether it will help, but I 
might as well point out that, in essence, I wrote 12.4.4.  Approximately 
20 years ago, during the development of Fortran 90, I was a member of 
the subgroup of X3J3 that looked at the question of how generics and 
host association should interact.  After the subgroup deliberations, I 
was given the task of writing a proposal to present to the full 
committee.  The proposal I wrote was adopted by X3J3 and the words of my 
proposal incorporated into the then current draft.  Since then, the 
location of those words in the standard has changed and there have been 
some changes to the words themselves (e.g., to handle user-defined 
elemental procedures), but the text of 12.4.4 is still primarily what I 
wrote approximately 20 years ago in Lake Tahoe.]

There is at least one legitimate interpretation question about this 
material.  Imagine we modified the example further by adding the 
INTENT(INOUT) attribute to N.  Is CALL SUBR(3) still resolved to SUBR2, 
and then considered in error because the actual argument is not 
definable, or does that potential error mean that instead we should 
bypass SUBR2 and resolve to SUBR1?  Is the answer any different if we 
use EXTERNAL in place of INTENT(INOUT) to get a different kind of 
error?  I have my own opinion about what the answers to these questions 
ought to be, but unlike the origiinal question, I don't believe X3J3 or 
its subgroups considered these questions in the writing of 12.4.4, so 
the interpretation of the text there with respect to these questions is 
much less certain.

-Kurt Hirchert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080318/99f63052/attachment.html