public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53164] Undefined reference to template function instantiation Date: Sat, 01 Apr 2023 14:19:17 +0000 [thread overview] Message-ID: <bug-53164-4-GCL3RSrgsd@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-53164-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53164 --- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:b5e38b1c166357e2a63d38ae6da7ae5d68fc115b commit r13-6970-gb5e38b1c166357e2a63d38ae6da7ae5d68fc115b Author: Patrick Palka <ppalka@redhat.com> Date: Sat Apr 1 10:19:08 2023 -0400 c++: improve "NTTP argument considered unused" fix [PR53164, PR105848] r13-995-g733a792a2b2e16 worked around the problem of (pointer to) function NTTP arguments not always getting marked as odr-used, by redundantly calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR. That is just a narrow workaround however, since it assumes the function is later called, but the use as a template argument alone should constitute an odr-use of the function (since template arguments are an evaluated context, and we're really passing its address); we shouldn't need to subsequently call or otherwise use the function NTTP argument. This patch fixes this in a more general way by walking the template arguments of each specialization that's about to be instantiated and redundantly calling mark_used on all entities used within. As before, the call to mark_used as it worst a no-op, but it compensates for the situation where the specialization was first formed in a template context in which mark_used is inhibited. Another approach would be to call mark_used whenever we substitute a TEMPLATE_PARM_INDEX, but that would result in many more redundant calls to mark_used compared to this approach. And as the second testcase below illustrates, we also need to walk C++20 class NTTP arguments which can be large and thus expensive to walk repeatedly. The change to invalid_tparm_referent_p is needed to avoid incorrectly rejecting class NTTP arguments containing function pointers as in the testcase. (The third testcase is unrelated to this fix, but it helped rule out an earlier approach I was considering and it seems we don't have existing test coverage for this situation.) PR c++/53164 PR c++/105848 gcc/cp/ChangeLog: * pt.cc (invalid_tparm_referent_p): Accept ADDR_EXPR of FUNCTION_DECL. (instantiate_class_template): Call mark_template_arguments_used. (tsubst_copy_and_build) <case CALL_EXPR>: Revert r13-995 change. (mark_template_arguments_used): Define. (instantiate_body): Call mark_template_arguments_used. gcc/testsuite/ChangeLog: * g++.dg/template/fn-ptr3a.C: New test. * g++.dg/template/fn-ptr3b.C: New test. * g++.dg/template/fn-ptr4.C: New test.
prev parent reply other threads:[~2023-04-01 14:19 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-30 9:46 [Bug c++/53164] New: " poletti.marco at gmail dot com 2012-04-30 10:46 ` [Bug c++/53164] " redi at gcc dot gnu.org 2021-08-12 2:21 ` pinskia at gcc dot gnu.org 2021-10-05 14:25 ` ppalka at gcc dot gnu.org 2022-06-06 18:29 ` cvs-commit at gcc dot gnu.org 2022-07-21 16:48 ` cvs-commit at gcc dot gnu.org 2022-08-11 13:23 ` ppalka at gcc dot gnu.org 2023-04-01 14:19 ` cvs-commit at gcc dot gnu.org [this message]
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-53164-4-GCL3RSrgsd@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).