Here is a slightly reduced test case (without unlimited polymorphism):

module kleiner
  implicit none

  type mytype
  contains
    generic, public            :: assignment(=) => assign
    procedure, private         :: assign        => ass_en
  end type

contains

  subroutine ass_en (result, incoming)
    class (mytype), intent(out) :: result
    class (mytype), intent(in)  :: incoming
  end subroutine

end module


module grosser
  use kleiner, only: mytype
  implicit none

  type, extends(mytype) :: zwotype
    contains
      generic            :: assignment(=) => assign2
      procedure, private :: assign2 => ass_gf
  end type

contains

  subroutine ass_gf (result, incoming)
    class (zwotype), intent(out) :: result
    class (zwotype) ,intent(in)  :: incoming
  end subroutine

end module


It fails with 4.6 up to trunk with this bogus error:

      generic            :: assignment(=) => assign2
                                            1
Error: 'ass_gf' and 'ass_en' for GENERIC '=' at (1) are ambiguous

It is fixed by this simple patch:

Index: gcc/fortran/interface.c
===================================================================
--- gcc/fortran/interface.c	(revision 206428)
+++ gcc/fortran/interface.c	(working copy)
@@ -1513,7 +1513,8 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
 	else
 	  {
 	    /* Only check type and rank.  */
-	    if (!compare_type (f2->sym, f1->sym))
+	    if (!compare_type (f1->sym, f2->sym)
+		|| !compare_type (f2->sym, f1->sym))
 	      {
 		if (errmsg != NULL)
 		  snprintf (errmsg, err_len, "Type mismatch in argument '%s' "

(In reply to janus from comment #2)
> It is fixed by this simple patch:

The patch fails on typebound_operator_14.f90 in the testsuite, which is very similar to the test case here and comes from PR 52024, where Tobias concluded that is was indeed ambiguous.

I will re-check the Fortran standard on this issue ...

(In reply to janus from comment #3)
> I will re-check the Fortran standard on this issue ...

The relevant section in the F08 standard is 12.4.3.4.5, which says:

"Two dummy arguments are distinguishable if [...] they are both data objects or known to be functions, and neither is TKR compatible with the other, ..."

In our case, wher

In our case here, the two corresponding arguments are polymorphic, with the type of the second one being an extension of the type of the first.

Therefore the second one is type-compatible with the first (but not vice versa), which means that they are *not* distinguishable, i.e. the two procedures *are* ambiguous.


Following this argumentation, gfortran is indeed correct to reject the test cases in comment 0 and 1 (as well as typebound_operator_14.f90), and my patch in comment 2 is wrong!

However, the question then is why Intel (and NAG?) seem to accept those test cases? Is this a bug in those compilers or do they just allow it as an extension?

To add to this discussion, here are two examples from the F08 standard (section C.9.6):


module fruits

  type :: fruit
  end type

  type, extends(fruit) :: apple
  end type
  
  type, extends(fruit) :: pear
  end type

  type, extends(pear) :: bosc
  end type

  INTERFACE BAD6 ! this interface is invalid !
    SUBROUTINE S6A(X,Y)
      import :: pear
      CLASS(PEAR) :: X,Y
    END SUBROUTINE S6A
    SUBROUTINE S6B(X,Y)
      import :: fruit, bosc
      CLASS(FRUIT) :: X
      CLASS(BOSC) :: Y
    END SUBROUTINE S6B
  END INTERFACE BAD6
  
  INTERFACE GOOD7
    SUBROUTINE S7A(X,Y,Z)
      import :: pear
      CLASS(PEAR) :: X,Y,Z
    END SUBROUTINE S7A
    SUBROUTINE S7B(X,Z,W)
      import :: fruit, bosc, apple
      CLASS(FRUIT) :: X
      CLASS(BOSC) :: Z
      CLASS(APPLE),OPTIONAL :: W
    END SUBROUTINE S7B
  END INTERFACE GOOD7

end


gfortran correctly rejects the first one and allows the second (both with and without the patch in comment 2).

However, ifort 12.1 seems to accept both, which clearly violates the F08 standard. I also tried flags like -std03 and -std08, without any effect. Are there other flags to force a more strict adherence to the standard?

Is anyone able to check other compilers?

(In reply to janus from comment #6)
> To add to this discussion, here are two examples from the F08 standard
> (section C.9.6):
> 
> 
> module fruits
[...]
> end
> 
> 
> gfortran correctly rejects the first one and allows the second (both with
> and without the patch in comment 2).
> 
> However, ifort 12.1 seems to accept both, which clearly violates the F08
> standard. I also tried flags like -std03 and -std08, without any effect. Are
> there other flags to force a more strict adherence to the standard?
> 
> Is anyone able to check other compilers?

xlf 14.1:
"pr59720a.f90", line 20.4: 1514-699 (S) Procedure "s6b" must have a nonoptional dummy argument that corresponds by position in the argument list to a dummy argument not present in procedure "s6a", present and type incompatible, present with different kind type parameters, or present with a different rank.

NAG Fortran Compiler Release 5.3.2(951)
Error: pr59720a.f90, line 40: Ambiguous specific names S6B and S6A in generic BAD6
Errors in declarations, no further processing for FRUITS

pgfortran 13.10 accepts it.

(In reply to Harald Anlauf from comment #7)

Thanks for checking, Harald. So XLF and NAG agree with gfortran on comment 6. That's the easy part (since the interpretation of these cases is explicitly given in the standard). Apparently ifort and pgfortran are buggy in this area.

Could you also check what XLF and NAG report on comment 1 (which is a somewhat more questionable case)?

(In reply to janus from comment #8)
> (In reply to Harald Anlauf from comment #7)
> 
> Thanks for checking, Harald. So XLF and NAG agree with gfortran on comment
> 6. That's the easy part (since the interpretation of these cases is
> explicitly given in the standard). Apparently ifort and pgfortran are buggy
> in this area.
> 
> Could you also check what XLF and NAG report on comment 1 (which is a
> somewhat more questionable case)?

Here we go:

% xlf2008 pr59720.f90
** kleiner   === End of Compilation 1 ===
"pr59720.f90", line 42.44: 1514-699 (S) Procedure "ass_gf" must have a nonoptional dummy argument that corresponds by position in the argument list to a dummy argument not present in procedure "ass_en", present and type incompatible, present with different kind type parameters, or present with a different rank.

% nagfor pr59720.f90
NAG Fortran Compiler Release 5.3.2(951)
Error: pr59720.f90, line 65: Ambiguous specific type-bound procedures ASSIGN2 and ASSIGN for type-bound generic ASSIGNMENT(=) in type MYTYPE
Errors in declarations, no further processing for GROSSER


Apparently both agree with gfortran ;-)

(In reply to Harald Anlauf from comment #9)
> > Could you also check what XLF and NAG report on comment 1 (which is a
> > somewhat more questionable case)?
> 
> Apparently both agree with gfortran ;-)

... and with my interpretation of the standard in comment 5. Great. Thanks a lot!

Paul, I think you should rather report the bug with Intel. I'm closing this PR as invalid. Thanks for reporting the difference in behavior, nevertheless!