[Bug c++/64562] New: Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous

[Bug c++/64562] New: Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous

[sneves at dei dot uc.pt]

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

            Bug ID: 64562
           Summary: Member functions with r-value reference for *this and
                    deduced return type incorrectly rejected as ambiguous
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sneves at dei dot uc.pt

Consider the following program:

#include <iostream>

#define RETURN_TYPE auto

namespace {

struct S {
  RETURN_TYPE operator--() && {
    return 1;
  }

  RETURN_TYPE operator--() const && {
    return 2;
  }

  RETURN_TYPE operator--() & {
    return 3;
  }

  RETURN_TYPE operator--() const & {
    return 4;
  }
};

const S callme() { return {}; }

auto f1() {
  return --S();
}

auto f2() {
  return --callme();
}

auto f3() {
  S s;
  return --s;
}

auto f4() {
  const S s {};
  return --s;
}

}

int main() {
  std::cout << f1() << " ";
  std::cout << f2() << " ";
  std::cout << f3() << " ";
  std::cout << f4() << std::endl;
}

The expected output would be "1 2 3 4". When RETURN_TYPE is defined to be
"int", this is the result obtained. GCC (versions ranging from 4.8.2 to the
latest build), however, rejects this code when RETURN_TYPE is defined to be
"auto" or "decltype(auto)".

[Bug c++/64562] Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-12
                 CC|                            |ville.voutilainen at gmail dot com
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2, 4.9.1, 5.0

--- Comment #1 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Reducing the test slightly, removing iostreams:

#define RETURN_TYPE auto

namespace {

struct S {
  RETURN_TYPE operator--() && {
    return 1;
  }

  RETURN_TYPE operator--() const && {
    return 2;
  }

  RETURN_TYPE operator--() & {
    return 3;
  }

  RETURN_TYPE operator--() const & {
    return 4;
  }
};

const S callme() { return {}; }

auto f1() {
  return --S();
}

auto f2() {
  return --callme();
}

auto f3() {
  S s;
  return --s;
}

auto f4() {
  const S s {};
  return --s;
}

}

int main() {
  f1();
  f2();
  f3();
  f4();
}

[Bug c++/64562] Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous

[splinterofchaos at gmail dot com]

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

--- Comment #2 from splinterofchaos at gmail dot com ---
Attempting a work-around on this problem...

struct S {
  RETURN_TYPE operator--() && {
    return 1;
  }

  RETURN_TYPE operator--() const && {
    return 2;
  }

  template<class = std::enable_if_t<true>>
  RETURN_TYPE operator--() & {
    return 3;
  }

  template<class = std::enable_if_t<true>>
  RETURN_TYPE operator--() const & {
    return 4;
  }
};

So, non-template functions have higher precedence, and I don't think it's valid
to convert an S& to an S&& or const S&&. But in fact, gcc (at least, 4.9) ends
up returning 1 for f3() and 2 for f4(). So, given an S&, it calls the S&&
overload, and given a const S&, it calls the const S&& overload.

clang, btw, does give the correct result, and rejects this code if you remove
the & and const & overloads.

So, this bug is maybe a bit bigger than ambiguity: gcc is picking an invalid
overload, and /that/'s creating the ambiguity!

[Bug c++/64562] Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to fail|                            |5.5.0
      Known to work|                            |6.1.0, 7.1.0
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |6.0

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 6+.