public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/66968] New: Incorrect template argument shown in diagnostic Date: Wed, 22 Jul 2015 13:37:00 -0000 [thread overview] Message-ID: <bug-66968-4@http.gcc.gnu.org/bugzilla/> (raw) [-- 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
next reply other threads:[~2015-07-22 13:37 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-07-22 13:37 redi at gcc dot gnu.org [this message] 2015-07-25 18:44 ` [Bug c++/66968] " manu at gcc dot gnu.org 2015-07-25 22:10 ` redi at gcc dot gnu.org 2021-07-16 20:24 ` redi at gcc dot gnu.org 2021-07-16 22:05 ` cvs-commit at gcc dot gnu.org 2021-07-16 22:11 ` redi at gcc dot gnu.org 2022-07-13 12:34 ` redi at gcc dot gnu.org 2023-02-06 10:18 ` vanyacpp at gmail dot com 2023-02-06 10:20 ` vanyacpp at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-66968-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).