[Bug fortran/59720] New: Re: f2003/f2008, class/extends, multiple gemeric assignment

[Bug fortran/59720] New: Re: f2003/f2008, class/extends, multiple gemeric assignment

[kapinos at rz dot rwth-aachen.de]

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

            Bug ID: 59720
           Summary: Re: f2003/f2008, class/extends, multiple gemeric
                    assignment
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kapinos at rz dot rwth-aachen.de

Created attachment 31773
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31773&action=edit
the attaches source cannot be compiled

As Janus Weil <janus(at)gcc.gnu.org> recommends in 
http://gcc.gnu.org/ml/fortran/2014-01/msg00048.html
.. here the ticket. 


> please take a look at the attached example. It cannot be compiled using the
> gfortran/4.8.1:
>
>> $ gfortran -c ___MOD_paul.f90
>> ___MOD_paul.f90:42.42:
>>
>>     generic            :: assignment(=) => assign2
>>                                           1
>> Error: 'ass_gf' and 'ass_en' for GENERIC '=' at (1) are ambiguous
>
> Actually this code piece is derived from an real world code which is
> developed using Intel compiler (may be compiled with ifort, runs OK) and the
> actual prevents from porting the code (being still in development) to
> 'gfortran'.
>
> Well, let's take a look at the code.
> - module 'kleiner' is no problem - can be compiled when in own file. Type
> 'mytype' is defined and '=' is bound to this type.
> - module 'grosser' is meant to be a subclass of 'kleiner': the type
> 'zwotype' extends the type 'mytype'. Again '=' should be bound to the new
> (derived) type 'zwotype' - and this fals.
>
> Well, as said the Intel's "ifort" compile this with no warnings and AFAIK
> the code also runs well. The question now is:
> - is that some Intel's extension, or
> - is that an Fortran 2003/2008 feature still not supported in gfortran, or
> - is the code in any way not Fortran-standard complying?

I think it's a bug in gfortran. Could you file a PR in bugzilla, please?

Thanks,
Janus

[Bug fortran/59720] Re: f2003/f2008, class/extends, multiple gemeric assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-08
     Ever confirmed|0                           |1

[Bug fortran/59720] [OOP] class/extends, multiple gemeric assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
                 CC|                            |janus at gcc dot gnu.org
            Summary|Re: f2003/f2008,            |[OOP] class/extends,
                   |class/extends, multiple     |multiple gemeric assignment
                   |gemeric assignment          |

--- Comment #1 from janus at gcc dot gnu.org ---
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

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
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' "

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(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 ...

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(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

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
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?

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
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?

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> ---
(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.

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(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)?

[Bug fortran/59720] [OOP] class/extends, multiple generic assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #10 from janus at gcc dot gnu.org ---
(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!