[Bug c++/66968] New: Incorrect template argument shown in diagnostic

[Bug c++/66968] New: Incorrect template argument shown in diagnostic

[redi at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6802 bytes --]

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

            Bug ID: 66968
           Summary: Incorrect template argument shown in diagnostic
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Compiling this invalid code produces an error as expected:

template<typename T> struct thing { };

template<typename T, typename XXX>
  bool operator==(const thing<T>&, const thing<XXX>&);

struct nested { typedef int name; };

template<typename A, typename B>
void func(typename A::name const&, const B) { }

template<typename A, typename B>
void func(typename A::name const&, const thing<B>) { }

int main()
{
  thing<int> ti;
  func<nested>(1, ti);
}


However the error has an error:

y.cc: In function ‘int main()’:
y.cc:17:21: error: call of overloaded ‘func(int, thing<int>&)’ is ambiguous
   func<nested>(1, ti);
                     ^
y.cc:9:6: note: candidate: void func(const typename A::name&, B) [with A =
nested; B = thing<int>; typename A::name = int]
 void func(typename A::name const&, const B) { }
      ^
y.cc:12:6: note: candidate: void func(const typename A::name&, thing<XXX>)
[with A = nested; B = int; typename A::name = int]
 void func(typename A::name const&, const thing<B>) { }
      ^


Note that the second candidate shows thing<XXX>, where does that XXX come
from?!

The "[with ...]" output correctly shows the template parameter B but B doesn't
appear in the candidate. For some reason XXX is shown instead, which is only
ever mentioned in the operator== declaration above, which is never used!
>From gcc-bugs-return-493016-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 22 13:52:47 2015
Return-Path: <gcc-bugs-return-493016-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13913 invoked by alias); 22 Jul 2015 13:52:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13704 invoked by uid 48); 22 Jul 2015 13:52:42 -0000
From: "julien.blanc at laposte dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
Date: Wed, 22 Jul 2015 13:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: julien.blanc at laposte dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60621-4-miRTHYW1ha@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60621-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60621-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01906.txt.bz2
Content-length: 1008

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

julien.blanc at laposte dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.blanc at laposte dot net

--- Comment #5 from julien.blanc at laposte dot net ---
Testing a bit, it really looks like the issue resides in how and where the
temporary string objects are created.

Changing marc’s code to have

struct S {
   S(const char* a, const char * b, const char *c);
};

makes it reverting back to only 0.3k more text (which can be explained because
two emplace_back function instanciation are needed vs one), and better
insertion performance (insertion time is worse otherwise, which breaks
emplace_back purpose).

The same goes if strings are constructed before being passed to S constructor.

(see new attachment).

Looks like an optimizer issue to me.

(note : tested with gcc 4.9.2)
>From gcc-bugs-return-493017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 22 13:53:41 2015
Return-Path: <gcc-bugs-return-493017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 34771 invoked by alias); 22 Jul 2015 13:53:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 34751 invoked by uid 48); 22 Jul 2015 13:53:37 -0000
From: "julien.blanc at laposte dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60621] std::vector::emplace_back generates massively more code than push_back
Date: Wed, 22 Jul 2015 13:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: julien.blanc at laposte dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-60621-4-5xnISwBsak@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60621-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60621-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01907.txt.bz2
Content-length: 232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`621

--- Comment #6 from julien.blanc at laposte dot net ---
Created attachment 36032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6032&actioníit
New version of marc's code

[Bug c++/66968] Incorrect template argument shown in diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
A dup of PR99 ?
>From gcc-bugs-return-493331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 25 18:52:00 2015
Return-Path: <gcc-bugs-return-493331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25088 invoked by alias); 25 Jul 2015 18:52:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25020 invoked by uid 55); 25 Jul 2015 18:51:56 -0000
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
Date: Sat, 25 Jul 2015 18:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mikael at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64986-4-yj1XyLw4Q7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64986-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64986-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02221.txt.bz2
Content-length: 598

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd986

--- Comment #17 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sat Jul 25 18:51:23 2015
New Revision: 226224

URL: https://gcc.gnu.org/viewcvs?rev"6224&root=gcc&view=rev
Log:
Fix gfortran.dg/class_to_type_4.f90 deallocation code misordering failure

        PR fortran/64986
gcc/fortran/
        * trans-expr.c (gfc_trans_assignment_1): Put component deallocation
        code at the beginning of the block.


Modified:
    branches/gcc-5-branch/gcc/fortran/ChangeLog
    branches/gcc-5-branch/gcc/fortran/trans-expr.c

[Bug c++/66968] Incorrect template argument shown in diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes maybe a dup of PR99 but it looks like all the examples in that bug involve
an overload and using the parameter names from the wrong overload. Here it uses
the parameter from a function that never participates in overload resolution.

[Bug c++/66968] Incorrect template argument shown in diagnostic

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2017-08-21 00:00:00         |2021-7-16

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Seen with std::tuple and std::get too:

t2.C:38:16: error: use of deleted function 'typename enable_if<(i >= sizeof...
(Elements))>::type get(const tuple<Elements ...>&) [with long unsigned int i =
1; Elements = {int}; typename enable_if<(i >= sizeof... (Elements))>::type =
void]'

It should be _Elements, but it shows _Types.

[Bug c++/66968] Incorrect template argument shown in diagnostic

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:3dbc7b809a62167b36f217ab5f43207be19e5908

commit r12-2379-g3dbc7b809a62167b36f217ab5f43207be19e5908
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jul 16 20:59:43 2021 +0100

    libstdc++: Improve diagnostics for std::get with invalid tuple index

    This adds a deleted overload of std::get<I>(const tuple<Types...>&).
    Invalid calls with an out of range index will match the deleted overload
    and give a single, clear error about calling a deleted function, instead
    of overload resolution errors for every std::get overload in the
    library.

    This changes the current output of 15+ errors (plus notes and associated
    header context) into just two errors (plus context):

    error: static assertion failed: tuple index must be in range
    error: use of deleted function 'constexpr std::__enable_if_t<(__i >=
sizeof... (_Types))> std::get(const std::tuple<_Types ...>&) [with long
unsigned int __i = 1; _Elements = {int}; std::__enable_if_t<(__i >= sizeof...
(_Types))> = void]'

    This seems like a nice improvement, although PR c++/66968 means that
    "_Types" is printed in the signature rather than "_Elements".

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            * include/std/tuple (get<I>): Add deleted overload for bad
            index.
            * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust
            expected errors.

[Bug c++/66968] Incorrect template argument shown in diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
To reproduce the std::tuple error above, use this code at r12-2379

#include <tuple>
std::tuple<int> t;
auto a = std::get<1>(t);

[Bug c++/66968] Incorrect template argument shown in diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Here's another case, using the code from PR 106281:

template<class A, class B>
class C
{
public:
  C() = default;

  template<class AA, class BB>
    C(AA, BB)
    { }

  C(C&&) = default;

private:
  struct __secret_tag  { };
  template<class AA, class BB>
    C(AA&, BB&, __secret_tag)
    { }
};

C<int, int> c({}, {});


Among the overload resolution candidates we get:

cons.C:8:5: note: candidate: ‘template<class AA, class BB> C<A, B>::C(AA, BB)
[with BB = AA; A = int; B = int]’


Where does "with BB = AA" come from?!

[Bug c++/66968] Incorrect template argument shown in diagnostic

[vanyacpp at gmail dot com]

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

Ivan Sorokin <vanyacpp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanyacpp at gmail dot com

--- Comment #9 from Ivan Sorokin <vanyacpp at gmail dot com> ---
*** Bug 108676 has been marked as a duplicate of this bug. ***

[Bug c++/66968] Incorrect template argument shown in diagnostic

[vanyacpp at gmail dot com]

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

--- Comment #10 from Ivan Sorokin <vanyacpp at gmail dot com> ---
One more case (from 108676):

template <typename T>
struct X
{};

template <typename U>
X<U&> f();

template <typename V>
X<V&> g();

int main()
{
    g<void>();
}

Here 'X<U&>' is printed in the error message instead of 'X<V&>'.