Re: c++/3585: wrong function overload resolution?

Re: c++/3585: wrong function overload resolution?

[Martin Sebor]

The following reply was made to PR c++/3585; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/3585: wrong function overload resolution?
Date: Fri, 06 Jul 2001 10:53:13 -0600

 gawrilow@math.tu-berlin.de wrote:
 > 
 > >Number:         3585
 > >Category:       c++
 > >Synopsis:       wrong function overload resolution?
 ...
 > >Description:
 > Let's consider the following fragment:
 > 
 > void f(int& x) { }  // #1
 > 
 > void f(int x) { }   // #2
 > 
 > int temp() { return 0; }
 > 
 > int main() {
 >   int var=0;
 >   f(var);       // should resolve to #1
 >   f(temp());    // resolves to #2
 > }
 > 
 > The gcc rejects f(var) as ambiguous reasoning that #1 and #2
 > were equally good. IMHO, resolving to #2 includes an
 > lvalue-to-rvalue conversion, where #1 incurs an identity
 > conversion, thus being better. Am I missing something?
 
 I think so: Reference Binding is considered the Identity conversion
 (see 13.3.3.1.4, p1).
 
 > 
 > The things become yet prettier as we move to templates.
 > Let's change the definitions of f's to the following:
 > 
 > template <class T> void f(T& x) { } // #1
 > template <class T> void f(T x) { } // #2
 > 
 > gcc 3.0 still considers this ambiguous, while 2.95 has
 > chosen #1 for f(var) without any complains.
 
 The call to f (var) is also ambiguous here. Argument deduction
 finds [T = int] in both cases and you're left with the same as
 above.
 
 > 
 > Thus the final questions: who understands the overload
 > resolution rules better: gcc 3.0, gcc 2.95,
 > me (obviously not!), or somebody else?
 
 I'd say 3.0 is correct here and 2.95 is in error. Most other
 compilers agree.
 
 > 
 > How could I otherwise distinct between rvalue and lvalue
 > arguments to an overloaded function, without using
 > f(const T&) ?
 
 Here's how you can tell an lvalue from an rvalue:
 
 bool is_lvalue (...) { return false; }
 
 template <class T> 
 bool is_lvalue (T&) { return true; }
 
 Regards
 Martin

Re: c++/3585: wrong function overload resolution?

[Gabriel Dos Reis]

The following reply was made to PR c++/3585; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: gawrilow@math.tu-berlin.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/3585: wrong function overload resolution?
Date: 06 Jul 2001 15:49:45 +0200

 gawrilow@math.tu-berlin.de writes:
 
 | >Number:         3585
 | >Category:       c++
 | >Synopsis:       wrong function overload resolution?
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       medium
 | >Responsible:    unassigned
 | >State:          open
 | >Class:          rejects-legal
 | >Submitter-Id:   net
 | >Arrival-Date:   Fri Jul 06 04:06:01 PDT 2001
 | >Closed-Date:
 | >Last-Modified:
 | >Originator:     Ewgenij Gawrilow
 | >Release:        3.0
 | >Organization:
 | >Environment:
 | Sun UltraSPARC, Solaris 8
 | >Description:
 | Let's consider the following fragment:
 | 
 | void f(int& x) { }  // #1
 | 
 | void f(int x) { }   // #2
 
 Nobody should be writing that :-)
 
 | int temp() { return 0; }
 | 
 | int main() {
 |   int var=0;
 |   f(var);       // should resolve to #1
 
 On what basis?
 
 |   f(temp());    // resolves to #2
 | }
 | 
 | The gcc rejects f(var) as ambiguous reasoning that #1 and #2
 | were equally good.
 
 GCC is right in doing so.
 
 | IMHO, resolving to #2 includes an
 | lvalue-to-rvalue conversion, where #1 incurs an identity
 | conversion, thus being better. Am I missing something?
 
 identity and lvalue-to-rvalue conversion both have Exact Match rank.
 See Table 9.
 
 | Thus the final questions: who understands the overload
 | resolution rules better: gcc 3.0, gcc 2.95,
 
 GCC-3.0.
 
 | How could I otherwise distinct between rvalue and lvalue
 | arguments to an overloaded function, without using
 | f(const T&) ?
 
 You cannot because both lvalue-transformation and identity
 transformation have Exact Match rank.
 
 -- Gaby

Re: c++/3585: wrong function overload resolution?

[gdr]

Synopsis: wrong function overload resolution?

Responsible-Changed-From-To: unassigned->gdr
Responsible-Changed-By: gdr
Responsible-Changed-When: Fri Jul  6 06:51:22 2001
Responsible-Changed-Why:
    Analysed.
State-Changed-From-To: open->closed
State-Changed-By: gdr
State-Changed-When: Fri Jul  6 06:51:22 2001
State-Changed-Why:
    Not a bug.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3585&database=gcc

c++/3585: wrong function overload resolution?

[gawrilow]

>Number:         3585
>Category:       c++
>Synopsis:       wrong function overload resolution?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 06 04:06:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Ewgenij Gawrilow
>Release:        3.0
>Organization:
>Environment:
Sun UltraSPARC, Solaris 8
>Description:
Let's consider the following fragment:

void f(int& x) { }  // #1

void f(int x) { }   // #2

int temp() { return 0; }

int main() {
  int var=0;
  f(var);       // should resolve to #1
  f(temp());    // resolves to #2
}

The gcc rejects f(var) as ambiguous reasoning that #1 and #2
were equally good. IMHO, resolving to #2 includes an
lvalue-to-rvalue conversion, where #1 incurs an identity
conversion, thus being better. Am I missing something?

The things become yet prettier as we move to templates.
Let's change the definitions of f's to the following:

template <class T> void f(T& x) { } // #1
template <class T> void f(T x) { } // #2

gcc 3.0 still considers this ambiguous, while 2.95 has
chosen #1 for f(var) without any complains.

Thus the final questions: who understands the overload
resolution rules better: gcc 3.0, gcc 2.95,
me (obviously not!), or somebody else?

How could I otherwise distinct between rvalue and lvalue
arguments to an overloaded function, without using
f(const T&) ?

Thanks in advance for any hint!
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: