[Bug c++/104996] New: Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[Bug c++/104996] New: Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[davveston at gmail dot com]

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

            Bug ID: 104996
           Summary: Overload resolution over rvalue/const lvalue array
                    reference parameters for an init. list argument
                    incorrectly picks the const lvalue ref. overload
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: davveston at gmail dot com
  Target Milestone: ---

GCC, MSVC and Clang all agrees and picks the rvalue overload for these two
examples:

 #include <cstddef>

 // #g.1: rvalue reference function parameter
 constexpr bool g(int&&)       { return true; }

 // #g.2: const lvalue reference function parameter
 constexpr bool g(int const&)  { return false; }

 static_assert(g(0), ""); // OK: all compilers agree

 // #f.1: rvalue ref overload
 template<std::size_t size>
 constexpr bool f(int (&&)[size])      { return true; }

 // #f.2: lvalue ref overload
 template<std::size_t size>
 constexpr bool f(int const (&)[size]) { return false; }

 template<typename T>
 using type = T;

 static_assert(f(type<int[3]>{1, 2, 3})); // OK: all compilers agree.

As expected, as per
https://timsong-cpp.github.io/cppwp/n4868/over.ics.rank#3.2.3.

However for a call to the `f` overloads with an initializer list argument GCC
picks the lvalue ref overload #f.2 whereas Clang and MVSC picks the rvalue ref
overload #f.1.

Afaict Clang and MSVC are correct, as per
https://timsong-cpp.github.io/cppwp/n4868/over.ics.list#9, particularly (albeit
non-normative) covered by /Note 2.

> Otherwise, if the parameter is a reference, see [over.ics.ref].
> 
> [Note 2: The rules in this subclause will apply **for initializing the underlying temporary for the reference.** — end note]

DEMO: https://godbolt.org/z/YbeKo4T1q

[Bug c++/104996] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ed at catmur dot uk]

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

--- Comment #1 from Ed Catmur <ed at catmur dot uk> ---
This should fix it:

https://github.com/gcc-mirror/gcc/compare/master...ecatmur:pr-104996

Please test and report back.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |10.4
      Known to fail|                            |10.3.0, 11.2.0, 12.0
   Last reconfirmed|                            |2022-03-21
            Summary|Overload resolution over    |[10/11/12 Regression]
                   |rvalue/const lvalue array   |Overload resolution over
                   |reference parameters for an |rvalue/const lvalue array
                   |init. list argument         |reference parameters for an
                   |incorrectly picks the const |init. list argument
                   |lvalue ref. overload        |incorrectly picks the const
                   |                            |lvalue ref. overload
      Known to work|                            |9.4.0
     Ever confirmed|0                           |1

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
We started rejecting the commented out static_assert after
r10-3740-g89e0a492af5bec.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
For the record, the full rejects-valid testcase is:

// #g.1: rvalue reference function parameter
constexpr bool g(int&&)       { return true; }

// #g.2: const lvalue reference function parameter
constexpr bool g(int const&)  { return false; }

static_assert(g(0), ""); // OK: all compilers agree

// #f.1: rvalue ref overload
template<int size>
constexpr bool f(int (&&)[size])      { return true; }

// #f.2: lvalue ref overload
template<int size>
constexpr bool f(int const (&)[size]) { return false; }

template<typename T>
using type = T;

static_assert(f(type<int[3]>{1, 2, 3})); // OK: all compilers agree.

static_assert(f({1, 2, 3}), ""); // Clang: OK    (picks #f.1)
                                 // MSVC:  OK    (picks #f.1)
                                 // GCC:   Error (picks #f.2)

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ed at catmur dot uk]

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

--- Comment #4 from Ed Catmur <ed at catmur dot uk> ---
(In reply to Patrick Palka from comment #2)
> We started rejecting the commented out static_assert after
> r10-3740-g89e0a492af5bec.

Thanks, that accords with my analysis - the branch in call.cc:compare_ics that
should be refined to take only if the two arrays have same element type was
added there.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[ed at catmur dot uk]

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

--- Comment #5 from Ed Catmur <ed at catmur dot uk> ---
Posted https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592154.html

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
v2 posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593336.html

Looks like it addresses the comments by Marek and Jason.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:5bde80f48bcc594658c788895ad1fd86d0916fc2

commit r12-8208-g5bde80f48bcc594658c788895ad1fd86d0916fc2
Author: Ed Catmur <ed@catmur.uk>
Date:   Mon Apr 18 23:09:04 2022 +0100

    c++: Fall through for arrays of T vs T cv [PR104996]

    If two arrays do not have the exact same element type including
    qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]),
    which can still be distinguished by the lvalue-rvalue tiebreaker.

    By tightening this branch (in accordance with the letter of the Standard)
we
    fall through to the next branch, which tests whether they have different
    element type ignoring qualification and returns 0 in that case; thus we
only
    actually fall through in the T[...] vs. T cv[...] case, eventually
    considering the lvalue-rvalue tiebreaker at the end of compare_ics.

    Signed-off-by: Ed Catmur <ed@catmur.uk>

            PR c++/104996

    gcc/cp/ChangeLog:

            * call.cc (compare_ics): When comparing list-initialization
            sequences, do not return early.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/initlist129.C: New test.

[Bug c++/104996] [10/11 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c++/104996] [11 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.