* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
@ 2020-06-11 21:49 ` dominiq at lps dot ens.fr
2020-06-11 22:50 ` kargl at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-06-11 21:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
2020-06-11 21:49 ` [Bug fortran/95647] " dominiq at lps dot ens.fr
@ 2020-06-11 22:50 ` kargl at gcc dot gnu.org
2020-06-13 8:11 ` tkoenig at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-06-11 22:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
2020-06-11 21:49 ` [Bug fortran/95647] " dominiq at lps dot ens.fr
2020-06-11 22:50 ` kargl at gcc dot gnu.org
@ 2020-06-13 8:11 ` tkoenig at gcc dot gnu.org
2020-06-13 16:16 ` sgk at troutmask dot apl.washington.edu
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-06-13 8:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (2 preceding siblings ...)
2020-06-13 8:11 ` tkoenig at gcc dot gnu.org
@ 2020-06-13 16:16 ` sgk at troutmask dot apl.washington.edu
2021-01-22 17:53 ` longb at cray dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2020-06-13 16:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (3 preceding siblings ...)
2020-06-13 16:16 ` sgk at troutmask dot apl.washington.edu
@ 2021-01-22 17:53 ` longb at cray dot com
2021-02-07 16:35 ` jvdelisle at charter dot net
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: longb at cray dot com @ 2021-01-22 17:53 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (4 preceding siblings ...)
2021-01-22 17:53 ` longb at cray dot com
@ 2021-02-07 16:35 ` jvdelisle at charter dot net
2021-02-07 17:04 ` longb at cray dot com
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jvdelisle at charter dot net @ 2021-02-07 16:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (5 preceding siblings ...)
2021-02-07 16:35 ` jvdelisle at charter dot net
@ 2021-02-07 17:04 ` longb at cray dot com
2021-02-07 17:55 ` jvdelisle at charter dot net
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: longb at cray dot com @ 2021-02-07 17:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (6 preceding siblings ...)
2021-02-07 17:04 ` longb at cray dot com
@ 2021-02-07 17:55 ` jvdelisle at charter dot net
2021-02-08 0:30 ` kargl at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jvdelisle at charter dot net @ 2021-02-07 17:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (7 preceding siblings ...)
2021-02-07 17:55 ` jvdelisle at charter dot net
@ 2021-02-08 0:30 ` kargl at gcc dot gnu.org
2021-02-09 4:46 ` jvdelisle at charter dot net
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-02-08 0:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (8 preceding siblings ...)
2021-02-08 0:30 ` kargl at gcc dot gnu.org
@ 2021-02-09 4:46 ` jvdelisle at charter dot net
2021-02-12 15:58 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jvdelisle at charter dot net @ 2021-02-09 4:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (9 preceding siblings ...)
2021-02-09 4:46 ` jvdelisle at charter dot net
@ 2021-02-12 15:58 ` cvs-commit at gcc dot gnu.org
2021-02-12 21:05 ` cvs-commit at gcc dot gnu.org
2021-02-13 21:44 ` jvdelisle at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-12 15:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (10 preceding siblings ...)
2021-02-12 15:58 ` cvs-commit at gcc dot gnu.org
@ 2021-02-12 21:05 ` cvs-commit at gcc dot gnu.org
2021-02-13 21:44 ` jvdelisle at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-12 21:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug fortran/95647] operator(.eq.) and operator(==) treated differently
2020-06-11 21:14 [Bug fortran/95647] New: operator(.eq.) and operator(==) treated differently longb at cray dot com
` (11 preceding siblings ...)
2021-02-12 21:05 ` cvs-commit at gcc dot gnu.org
@ 2021-02-13 21:44 ` jvdelisle at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-02-13 21:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread