[Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently

[Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

            Bug ID: 95647
           Summary: operator(.eq.) and operator(==) treated differently
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
     program test
              use, intrinsic :: ieee_arithmetic, only :                 &
     &                ieee_class,                                       &
     &                ieee_class_type,                                  &
     &                ieee_negative_normal,                             &
     &                ieee_positive_normal,                             &
     &                operator(.eq.)

!             use, intrinsic :: ieee_arithmetic

              real(4) r4
              type(ieee_class_type) class1
              r4 = 1.0
              class1 = ieee_class(r4)
              if (class1 .eq. ieee_positive_normal) print *, 'yes'
              r4 = -1.0
              class1 = ieee_class(r4)
              if (class1 .eq. ieee_negative_normal) print *, 'yes'
      end program test



Try test.f90 with 3 compilers:

> ftn test.f90
 ./a.out
yes
yes
> module swap PrgEnv-cray PrgEnv-intel
> ifort test.f90
> ./a.out
yes
yes
> module swap PrgEnv-intel PrgEnv-gnu
> gfortran test.f90
test.f90:6:43:

6 | & ieee_positive_normal, &
1
Error: Intrinsic operator '.eq.' referenced at (1) not found in module
'ieee_arithmetic'
test.f90:13:18:

13 | if (class1 .eq. ieee_positive_normal) print *, 'yes'
1
Error: Operands of comparison operator '.eq.' at (1) are
TYPE(ieee_class_type)/TYPE(ieee_class_type)
test.f90:16:18:

16 | if (class1 .eq. ieee_negative_normal) print *, 'yes'
1
Error: Operands of comparison operator '.eq.' at (1) are
TYPE(ieee_class_type)/TYPE(ieee_class_type)



Alternate test case:



> diff test.f90 test1.f90

7c7

<      &                operator(.eq.)

---

>      &                operator(==)





Works better:

> ftn test1.f90
> ./a.out
yes
yes
> module swap PrgEnv-cray PrgEnv-intel
> ifort test1.f90
> ./a.out
yes
yes
> module swap PrgEnv-intel PrgEnv-gnu
> gfortran test1.f90
> ./a.out
yes
yes



Referencing .eq. or == should have the same effect.

Curiously, the case that works is the one where the USE ONLY clause specifies
operator(==) and the statements that reference that operator are written using
.eq.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-11
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed from at least GCC5.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Thanks for the testcase.  gfortran converts the old school .eq. to ==,
and then tracks the ==.  The module starts with == and so it does not
properly overload the .eq.  This fixes the issue.

Index: libgfortran/ieee/ieee_arithmetic.F90
===================================================================
--- libgfortran/ieee/ieee_arithmetic.F90        (revision 280157)
+++ libgfortran/ieee/ieee_arithmetic.F90        (working copy)
@@ -77,15 +77,16 @@ module IEEE_ARITHMETIC


   ! Equality operators on the derived types
-  interface operator (==)
+  ! Note, the FE overloads .eq. to == and .ne. to /=
+  interface operator (.eq.)
     module procedure IEEE_CLASS_TYPE_EQ, IEEE_ROUND_TYPE_EQ
   end interface
-  public :: operator(==)
+  public :: operator(.eq.)

-  interface operator (/=)
+  interface operator (.ne.)
     module procedure IEEE_CLASS_TYPE_NE, IEEE_ROUND_TYPE_NE
   end interface
-  public :: operator (/=)
+  public :: operator (.ne.)


   ! IEEE_IS_FINITE

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
If we treat .eq. and == differently, that is an indication
of a bug in the compiler itself.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Jun 13, 2020 at 08:11:22AM +0000, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
> 
> --- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> If we treat .eq. and == differently, that is an indication
> of a bug in the compiler itself.

If a user provides an overloading of .eq. or == with an
INTERFACE OPERATOR() statement, then things appear to work.

The IEEE modules are not provided by a user and for parts of
the modules gfortran builts the needed the pieces at compile
time.  gfortran also marks symbols as coming from an IEEE
module for special handling.  For whatever reason, with the
IEEE_ARITHMETICi module if the interface is given in terms
of ==, it is not overloaded to .eq.; while for the converse
.eq. is overloaded to ==.

The purposed patch fixes this issue.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #5 from Bill Long <longb at cray dot com> ---
Is this fixed in a release version of GCC?

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

Jerry DeLisle <jvdelisle at charter dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at charter dot net

--- Comment #6 from Jerry DeLisle <jvdelisle at charter dot net> ---
(In reply to Bill Long from comment #5)
> Is this fixed in a release version of GCC?

Submitting patch for approval and will backport as the fix is simple. How far
back shall we go? 10 for sure. Eyeballing the time lines, it does not look like
9 will have any more releases.  If someone knows otherwise, let me know.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #7 from Bill Long <longb at cray dot com> ---
For our purposes, 10 will be fine.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #8 from Jerry DeLisle <jvdelisle at charter dot net> ---
(In reply to Jerry DeLisle from comment #6)
> (In reply to Bill Long from comment #5)
> > Is this fixed in a release version of GCC?
> 
> Submitting patch for approval and will backport as the fix is simple. How
> far back shall we go? 10 for sure. Eyeballing the time lines, it does not
> look like 9 will have any more releases.  If someone knows otherwise, let me
> know.

While putting together a test case, I found another problem.

program test
  use, intrinsic :: ieee_arithmetic, only :                 &
&                ieee_class,                                       &
&                ieee_class_type,                                  &
&                ieee_negative_normal,                             &
&                ieee_positive_normal,                             &
&                operator(.eq.)
!             use, intrinsic :: ieee_arithmetic
  real(4) r4
  type(ieee_class_type) class1
  r4 = 1.0
  class1 = ieee_class(r4)
  if (class1 .eq. ieee_positive_normal) print *, 'yes'
  if (class1 .ne. ieee_negative_normal) print *, 'yes'
  r4 = -1.0
  class1 = ieee_class(r4)
  if (class1 .eq. ieee_negative_normal) print *, 'yes'
  if (class1 .ne. ieee_positive_normal) print *, 'yes'
end program test

$ gfc pr95647.f90 
pr95647.f90:14:6:

   14 |   if (class1 .ne. ieee_negative_normal) print *, 'yes'
      |      1
Error: Operands of comparison operator ‘.ne.’ at (1) are
TYPE(ieee_class_type)/TYPE(ieee_class_type)
pr95647.f90:18:6:

   18 |   if (class1 .ne. ieee_positive_normal) print *, 'yes'
      |      1
Error: Operands of comparison operator ‘.ne.’ at (1) are
TYPE(ieee_class_type)/TYPE(ieee_class_type)

There is more to the story apparently

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #8)
> (In reply to Jerry DeLisle from comment #6)
> > (In reply to Bill Long from comment #5)
> > > Is this fixed in a release version of GCC?
> > 
> > Submitting patch for approval and will backport as the fix is simple. How
> > far back shall we go? 10 for sure. Eyeballing the time lines, it does not
> > look like 9 will have any more releases.  If someone knows otherwise, let me
> > know.
> 
> While putting together a test case, I found another problem.
> 
> program test
>   use, intrinsic :: ieee_arithmetic, only :                 &
> &                ieee_class,                                       &
> &                ieee_class_type,                                  &
> &                ieee_negative_normal,                             &
> &                ieee_positive_normal,                             &
> &                operator(.eq.)
> !             use, intrinsic :: ieee_arithmetic
>   real(4) r4
>   type(ieee_class_type) class1
>   r4 = 1.0
>   class1 = ieee_class(r4)
>   if (class1 .eq. ieee_positive_normal) print *, 'yes'
>   if (class1 .ne. ieee_negative_normal) print *, 'yes'
>   r4 = -1.0
>   class1 = ieee_class(r4)
>   if (class1 .eq. ieee_negative_normal) print *, 'yes'
>   if (class1 .ne. ieee_positive_normal) print *, 'yes'
> end program test
> 
> $ gfc pr95647.f90 
> pr95647.f90:14:6:
> 
>    14 |   if (class1 .ne. ieee_negative_normal) print *, 'yes'
>       |      1
> Error: Operands of comparison operator ‘.ne.’ at (1) are
> TYPE(ieee_class_type)/TYPE(ieee_class_type)
> pr95647.f90:18:6:
> 
>    18 |   if (class1 .ne. ieee_positive_normal) print *, 'yes'
>       |      1
> Error: Operands of comparison operator ‘.ne.’ at (1) are
> TYPE(ieee_class_type)/TYPE(ieee_class_type)
> 
> There is more to the story apparently

gfortran is correct to issue an error.  You forgot to include
'operator(.ne.)' in the only clause of your test program.  Neither
'.ne.' nor '==' are overloaded for the class.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #10 from Jerry DeLisle <jvdelisle at charter dot net> ---
Oops, that what I get for doing 16 things at once. sorry.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:0631e008adc759cc801d0d034224ee6b4bcf31aa

commit r11-7225-g0631e008adc759cc801d0d034224ee6b4bcf31aa
Author: Steve Kargl <sgk@troutmask.apl.washington.edu>
Date:   Fri Feb 12 07:58:16 2021 -0800

    libgfortran: Fix PR95647 by changing the interfaces of operators .eq. and
.ne.

    The FE converts the old school .eq. to ==,
    and then tracks the ==.  The module starts with == and so it does not
    properly overload the .eq.  Reversing the interfaces fixes this.

    2021-02-12  Steve Kargl <sgk@troutmask.apl.washington.edu>

    libgfortran/ChangeLog:

            PR libfortran/95647
            * ieee/ieee_arithmetic.F90: Flip interfaces of operators .eq. to
            == and .ne. to /= .

    gcc/testsuite/ChangeLog:

            PR libfortran/95647
            * gfortran.dg/ieee/ieee_12.f90: New test.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jerry DeLisle
<jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:d5021162cf33081c128cd5c4f96ea0b7ca8739d7

commit r10-9365-gd5021162cf33081c128cd5c4f96ea0b7ca8739d7
Author: Steve Kargl <sgk@troutmask.apl.washington.edu>
Date:   Fri Feb 12 13:04:14 2021 -0800

    libgfortran: Fix PR95647 by changing the interfaces of operators .eq. and
.ne.

    The FE converts the old school .eq. to ==,
    and then tracks the ==.  The module starts with == and so it does not
    properly overload the .eq.  Reversing the interfaces fixes this.

    2021-02-12  Steve Kargl <sgk@troutmask.apl.washington.edu>

    libgfortran/ChangeLog:

            PR libfortran/95647
            * ieee/ieee_arithmetic.F90: Flip interfaces of operators .eq. to
            == and .ne. to /= .

    gcc/testsuite/ChangeLog:

            PR libfortran/95647
            * gfortran.dg/ieee/ieee_12.f90: New test.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk and gcc-10