[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.05.28 21:44:52
AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #8 from Thomas Koenig 2011-05-28
21:44:52 UTC ---
Which test cases still fail, and which ones are fixed?
It is a bit unclear from the log...(In reply to comment #7)
> So what is the status of this defect? It would appear to be "will not fix".
The status is more like "Nobody hasn't gotten a round tuit"...
Looking at the original test case, this now fails because the
public statement for == does not pick up the interface for .eq.
This can be seen from the module dump.
If you remove the "private", or use "interface operator(.eq.)", then
it works. Hmm...
This patch
Index: decl.c
===
--- decl.c (revision 173754)
+++ decl.c (working copy)
@@ -6478,9 +6478,24 @@
case INTERFACE_INTRINSIC_OP:
if (gfc_current_ns->operator_access[op] == ACCESS_UNKNOWN)
{
+ gfc_intrinsic_op same_op;
+
+ same_op = INTRINSIC_NONE;
+
gfc_current_ns->operator_access[op] =
(st == ST_PUBLIC) ? ACCESS_PUBLIC : ACCESS_PRIVATE;
+
+ if (op == INTRINSIC_EQ)
+ same_op = INTRINSIC_EQ_OS;
+ else if (op == INTRINSIC_EQ_OS)
+ same_op = INTRINSIC_EQ;
+
+ if (same_op != INTRINSIC_NONE)
+ gfc_current_ns->operator_access[same_op] =
+ (st == ST_PUBLIC) ? ACCESS_PUBLIC : ACCESS_PRIVATE;
+
}
+
else
{
gfc_error ("Access specification of the %s operator at %C has "
seems to fix the bug. It doesn't fix all cases, because it only
looks at == and .eq. and not at the other operators, but the principle
appears to be sound.
Let's see if we can get this fixed for 4.7.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #7 from neil.n.carlson at gmail dot com 2011-05-28 18:14:04 UTC --- So what is the status of this defect? It would appear to be "will not fix".
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
Daniel Franke changed:
What|Removed |Added
CC||dfranke at gcc dot gnu.org
--- Comment #6 from Daniel Franke 2010-12-16
00:25:54 UTC ---
Shot in the dark, isn't this related to ...
typedef enum
{ [...]
/* ==, /=, >, >=, <, <= */
INTRINSIC_EQ, INTRINSIC_NE, INTRINSIC_GT, INTRINSIC_GE,
INTRINSIC_LT, INTRINSIC_LE,
/* .EQ., .NE., .GT., .GE., .LT., .LE. (OS = Old-Style) */
INTRINSIC_EQ_OS, INTRINSIC_NE_OS, INTRINSIC_GT_OS, INTRINSIC_GE_OS,
INTRINSIC_LT_OS, INTRINSIC_LE_OS,
[...]
}
gfc_intrinsic_op;
... which was introduced to ...
(In reply to comment #5)
> IIRC, it used to be that way but it was changed to emit better diagnostics.
Hence
(In reply to comment #1)
> interface operator(.eq.)
>module procedure eq_foo
> end interface operator(==)
would be begun with INTRINSIC_EQ_OS as operator and closed with INTRINSIC_EQ?!
If the one style is silently converted to another style during parsing, the
above could be undone?
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot ||gnu.org --- Comment #5 from Francois-Xavier Coudert 2010-10-03 12:21:32 UTC --- (In reply to comment #3) > I think it is more of a bandaid than a proper fix > in that I think .eq. should be simply substituted > with == on the input stream during parsing. IIRC, it used to be that way but it was changed to emit better diagnostics.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #4 from Steve Kargl 2010-09-25 05:57:30 UTC --- On Sat, Sep 25, 2010 at 03:00:37AM +, sgk at troutmask dot apl.washington.edu wrote: > On Sat, Sep 25, 2010 at 12:16:53AM +, kargl at gcc dot gnu.org wrote: > > > > Interesting**3. If you simply remove the private > > and public statement then everything works as one > > would expect. > > > > And finally, an even more interesting bug. > > Change the interface statement to > > > > interface operator(.eq.) > > module procedure eq_foo > > end interface operator(==) > > I have a patch that appears to fix this one. > I think it is more of a bandaid than a proper fix > in that I think .eq. should be simply substituted > with == on the input stream during parsing. > The patch was committed as svn-commit.tmp: 8 lines, 286 characters. Sendinggcc/fortran/ChangeLog Sendinggcc/fortran/interface.c Sendinggcc/testsuite/ChangeLog Adding gcc/testsuite/gfortran.dg/operator_c1202.f90 Transmitting file data Committed revision 164616. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #3 from Steve Kargl 2010-09-25 03:00:24 UTC --- On Sat, Sep 25, 2010 at 12:16:53AM +, kargl at gcc dot gnu.org wrote: > > Interesting**3. If you simply remove the private > and public statement then everything works as one > would expect. > > And finally, an even more interesting bug. > Change the interface statement to > > interface operator(.eq.) > module procedure eq_foo > end interface operator(==) I have a patch that appears to fix this one. I think it is more of a bandaid than a proper fix in that I think .eq. should be simply substituted with == on the input stream during parsing. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #2 from neil.n.carlson at gmail dot com 2010-09-25 00:27:24 UTC --- Note also that the problem isn't restricted to .eq./== ; it appears to occur with all the other pairs of equivalent operators: .ne./!=, .lt./<, etc. At least the compiler is consistent :) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2010-09-25 00:16:43 UTC --- (In reply to comment #0) > The first paragraph of 7.2 in the standard states that "The operators <, ... > always have the same interpretations as the operators .LT., ..." Consider the > following example: > > module foo_type > private > public :: foo, operator(==) Interesting. If you replace == with .eq. in the the above everything works as expected. Interesting**2. If you leave the public statement intact, and change the .eq. in the following to == > interface operator(.eq.) >module procedure eq_foo > end interface everything works as expected. Interesting**3. If you simply remove the private and public statement then everything works as one would expect. And finally, an even more interesting bug. Change the interface statement to interface operator(.eq.) module procedure eq_foo end interface operator(==) This gives h.f90:7.28: end interface operator(==) 1 Error: Expecting 'END INTERFACE OPERATOR (.eq.)' at (1) h.f90:8.10: The above violates C1202. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
