[Bug c++/17805] New: too liberal operator lookup

[Bug c++/17805] New: too liberal operator lookup

[rth at gcc dot gnu dot org]

struct  QCString
{
    QCString( int size ) {};
    QCString( const char *str ) {};
};
 
inline bool operator==( const QCString &s1, const QCString &s2 )
{ return 0; }
 
enum EStyle
{
    FS_SOLID
};
 
static EStyle   getFillStyle() { return FS_SOLID; }
 
int main()
{
    if(getFillStyle() == "FS_SOLID") {}
}

As I understand it, this is invalid code.  Alex Oliva writes:

Since one of the operands of == is a class or enumerated type [13.3.1.2]/1,
user-defined operators are candidate functions.  However, to avoid the very kind
of error you've observed, paragraph 3 of the same clause, that defines how the
candidate functions are selected, says, in the second bullet:
   [...] if no operand has a class type, only those non-
    member functions in the lookup set that have a  first  parameter  of
    type  T1 or "reference to (possibly cv-qualified) T1", when T1 is an
    enumeration type, or (if there is a right operand) a second  parame-
    ter of type T2 or "reference to (possibly cv-qualified) T2", when T2
    is an enumeration type, are candidate functions.

Affects at least gcc 3.2 and forward.

-- 
           Summary: too liberal operator lookup
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rth at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/17805] too liberal operator lookup

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-03 20:04 -------
Hmm, Comeau online tester accepts the code too.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid


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

[Bug c++/17805] too liberal operator lookup

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-04 17:37 -------
Here's a reduced version:

=======================================
struct A
{
    A(int);
    A(const char*);
};

bool operator==(const A&, const A&);

enum E { e };

bool b = (e == "");
=======================================

Btw, icc rejects it.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org


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

[Bug c++/17805] too liberal operator lookup

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 15:20 -------
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
           Keywords|                            |patch


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

[Bug c++/17805] too liberal operator lookup

[aoliva at redhat dot com]

------- Additional Comments From aoliva at gcc dot gnu dot org  2005-04-17 04:00 -------
Subject: Re: [PR c++/17805] limit operator overload candidates for enum operands

On Apr  2, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Mar 18, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Mar  1, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Feb 10, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>> We're a bit too lenient in creating the candidate list for overload
>>>> resolution for expressions that use user-defined operator functions.
>>>> This patch arranges for us to reject functions that don't get an exact
>>>> match for at least one of the enum-typed arguments, if none of the
>>>> arguments have class types.

>>>> Regression-tested on x86_64-linux-gnu.  Ok to install?

>>>> Index: gcc/cp/ChangeLog
>>>> from  Alexandre Oliva  <aoliva@redhat.com>

>>>> PR c++/17805
>>>> * call.c (build_new_op): Filter out operator functions that don't
>>>> satisfy enum-conversion match requirements.

>>> Ping?

>>> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html

>> Ping?

> Ping?

Ping?



-- 


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

[Bug c++/17805] too liberal operator lookup

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-04-17 06:31 -------
Subject: Re:  too liberal operator lookup

Why are you pinging bugzilla, and not the list, wherein a c++
maintainer might see it?


-- 


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

[Bug c++/17805] too liberal operator lookup

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-17 06:37 -------
(In reply to comment #5)
> Subject: Re:  too liberal operator lookup
> 
> Why are you pinging bugzilla, and not the list, wherein a c++
> maintainer might see it?
Actually he pinged both.

-- 


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

[Bug c++/17805] too liberal operator lookup

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-09-29 14:28 -------
The patch:

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html

is basically OK.  

However, please make the folloing changes before check-in:

+	      && (same_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (arg1)),
+			       TYPE_MAIN_VARIANT (parmtype))

Use same_type_ignoring_top_level_qualifiers_p.

+		  || (TREE_CODE (parmtype) == REFERENCE_TYPE
+		      && reference_related_p (TREE_TYPE (arg1),
+					      TREE_TYPE (parmtype)))))

That's silly. :-)  Two types are reference-related only if they are cv-qualified
variants of one-another, or class types derived from one-another.  The whole
point is that these aren't class types, so you want
same_type_ignoring_top_level_qualifiers_p again.  So, you really want something
like:

  if (TREE_CODE (parmtype) == REFERENCE_TYPE)
    parmtype = TREE_TYPE (parmtype);
  if (s_t_i_t_l_q_p (TREE_TYPE (arg1), parmtype))
    ...

Also, please code this using a loop:

  for (i = 0; i < 2; ++i) {
    if (i == 1 && !arg2)
      break;
    ...
  }

so that it is obvious that you were using the same tests on both arguments.

OK with those changes.

-- 


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

[Bug c++/17805] too liberal operator lookup

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-09-29 16:31 -------
Subject: Re:  too liberal operator lookup

On Thu, Sep 29, 2005 at 02:28:03PM -0000, mmitchel at gcc dot gnu dot org wrote:
> Also, please code this using a loop:
> 
>   for (i = 0; i < 2; ++i) {
>     if (i == 1 && !arg2)

Or better, 

  for (i = 0; i < (arg2 ? 2 : 1); ++i)


r~


-- 


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

[Bug c++/17805] too liberal operator lookup

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|paolo.carlini at oracle dot |
                   |com                         |
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.0

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-15 19:17:24 UTC ---
Fixed.

[Bug c++/17805] too liberal operator lookup

[paolo at gcc dot gnu.org]

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

--- Comment #11 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> 2012-10-15 19:15:51 UTC ---
Author: paolo
Date: Mon Oct 15 19:15:48 2012
New Revision: 192471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192471
Log:
/cp
2012-10-15  Alexandre Oliva  <aoliva@redhat.com>
        Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/17805
    * call.c (build_new_op): Filter out operator functions that don't
    satisfy enum-conversion match requirements.

/testsuite
2012-10-15  Alexandre Oliva  <aoliva@redhat.com>
        Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/17805
    * g++.dg/overload/operator6.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/overload/operator6.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/17805] too liberal operator lookup

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org,
                   |                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-01-21 22:10:25 UTC ---
Jason, better delaying this to Stage 1? Is the patch otherwise technically
ready to be reapplied to current mainline?!?

[Bug c++/17805] too liberal operator lookup

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-30 07:12:30         |2012-01-21 0:00

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-21 21:33:25 UTC ---
The patch was approved but never applied.