public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/53164] New: Undefined reference to template function instantiation
@ 2012-04-30  9:46 poletti.marco at gmail dot com
  2012-04-30 10:46 ` [Bug c++/53164] " redi at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: poletti.marco at gmail dot com @ 2012-04-30  9:46 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53164

             Bug #: 53164
           Summary: Undefined reference to template function instantiation
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: poletti.marco@gmail.com


Created attachment 27266
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27266
A (hopefully) minimal test case

g++ 4.6.2 gives an undefined reference error in the attached code.
It works fine in clang++.

Set the macro WORKAROUND to 1 to workaround the issue (also highlighting the
fact that the template function can be instantiated).


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation poletti.marco at gmail dot com
@ 2012-04-30 10:46 ` redi at gcc dot gnu.org
  2021-08-12  2:21 ` pinskia at gcc dot gnu.org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-30 10:46 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53164

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-30
     Ever Confirmed|0                           |1
           Severity|major                       |normal

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-30 10:46:39 UTC ---
Looks as though we need to call mark_used for function templates used as
non-type template parameters


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation 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
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-12  2:21 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 82657 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation 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
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-10-05 14:25 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Looks as though we need to call mark_used for function templates used as
> non-type template parameters

Yep :)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation poletti.marco at gmail dot com
                   ` (2 preceding siblings ...)
  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
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-06-06 18:29 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 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:733a792a2b2e1662e738fa358b45a2720a8618a7

commit r13-995-g733a792a2b2e1662e738fa358b45a2720a8618a7
Author: Patrick Palka <ppalka@redhat.com>
Date:   Mon Jun 6 14:29:12 2022 -0400

    c++: function NTTP argument considered unused [PR53164, PR105848]

    Here at parse time the template argument f (an OVERLOAD) in A<f> gets
    resolved ahead of time to the FUNCTION_DECL f<int>, and we defer marking
    f<int> as used until instantiation (of g) as usual.

    Later when instantiating g the type A<f> (where f has already been
    resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
    template arguments, and we end up never actually marking f<int> as used
    (which means we never instantiate it) even though A<f>::h() later calls
    it, leading to a link error.

    This patch works around this issue by looking through ADDR_EXPR when
    calling mark_used on the substituted callee of a CALL_EXPR.

            PR c++/53164
            PR c++/105848

    gcc/cp/ChangeLog:

            * pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Look through an
            ADDR_EXPR callee when calling mark_used.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/fn-ptr3.C: New test.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation poletti.marco at gmail dot com
                   ` (3 preceding siblings ...)
  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
  6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-07-21 16:48 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:670ef5b108d0acfbde96f44b064079f2fa0c92d4

commit r12-8604-g670ef5b108d0acfbde96f44b064079f2fa0c92d4
Author: Patrick Palka <ppalka@redhat.com>
Date:   Mon Jun 6 14:29:12 2022 -0400

    c++: function NTTP argument considered unused [PR53164, PR105848]

    Here at parse time the template argument f (an OVERLOAD) in A<f> gets
    resolved ahead of time to the FUNCTION_DECL f<int>, and we defer marking
    f<int> as used until instantiation (of g) as usual.

    Later when instantiating g the type A<f> (where f has already been
    resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
    template arguments, and we end up never actually marking f<int> as used
    (which means we never instantiate it) even though A<f>::h() later calls
    it, leading to a link error.

    This patch works around this issue by looking through ADDR_EXPR when
    calling mark_used on the substituted callee of a CALL_EXPR.

            PR c++/53164
            PR c++/105848

    gcc/cp/ChangeLog:

            * pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Look through an
            ADDR_EXPR callee when calling mark_used.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/fn-ptr3.C: New test.

    (cherry picked from commit 733a792a2b2e1662e738fa358b45a2720a8618a7)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation poletti.marco at gmail dot com
                   ` (4 preceding siblings ...)
  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
  6 siblings, 0 replies; 8+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-08-11 13:23 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |12.2

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 12.2/13

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/53164] Undefined reference to template function instantiation
  2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation poletti.marco at gmail dot com
                   ` (5 preceding siblings ...)
  2022-08-11 13:23 ` ppalka at gcc dot gnu.org
@ 2023-04-01 14:19 ` cvs-commit at gcc dot gnu.org
  6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-01 14:19 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-04-01 14:19 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-30  9:46 [Bug c++/53164] New: Undefined reference to template function instantiation 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 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).