Bug 5296 - [3.3/3.4 Regression] [DR115] Pointers to functions and template functions behave different in deduction
Summary: [3.3/3.4 Regression] [DR115] Pointers to functions and template functions beh...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 2.95.2
: P1 critical
Target Milestone: 3.3.2
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid, wrong-code
Depends on:
Blocks:
 
Reported: 2002-01-07 02:16 UTC by wolfgang.bangerth
Modified: 2004-01-17 04:22 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-08-03 15:19:03


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wolfgang.bangerth 2002-01-07 02:16:01 UTC
Pointers to regular functions and to template functions behave
differently. A simple example to show this is this:

      #include <iostream>
      #include <typeinfo>

      template <typename T>  void print_type (const T &) {
        std::cout << typeid(T).name() << std::endl;
      };

      /* no template */      void pp1 (int) {};
      template <typename X>  void pp2 (X)   {};

      int main () {
        print_type (&pp1);
        print_type (&pp2<int>);
      };

We try to print the data types (mangled) of a pointer to a function
and a pointer to a template function. With gcc2.95.2, this example is
compilable and yields as output:

    examples/step-1> c++ b.cc
    examples/step-1> ./a.out
--->    PFi_v
--->    Fi_v
    examples/step-1> c++ -v
    Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
    gcc version 2.95.2 19991024 (release)       

The two lines of output should be identical, but are not. With
gcc3.0.1 and SS20011107, the example is not compilable:

    examples/step-1> ~/bin/gcc-3.0.1/bin/c++ b.cc
    b.cc: In function `int main()':
    b.cc:13: no matching function for call to `print_type(<unknown type>)'           
    examples/step-1> ~/bin/gcc-3.0.1/bin/c++ -v
    Reading specs from /home/wolf/bin/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs
    Configured with: ../gcc-3.0.1/configure --prefix=/home/wolf/bin/gcc-3.0.1
    Thread model: single
    gcc version 3.0.1

Note that for both gcc versions, the problem disappears if we let
print_type take an argument of type `T' rather than `const T &'
(very strange).

The effect shown above results in the non-compilability of the
following example program:

   template <typename T> struct Capsule {  T t;  };

   template <typename T> void encapsulate (const T &) { Capsule<T> c; };

   /* no template */      void pp1 (int);
   template <typename X>  void pp2 (X);

   void foo() {
     encapsulate (&pp1);         // ok
     encapsulate (&pp2<int>);    // fails!?!
   };

With gcc2.95.2:
          examples/step-1> c++ -c a.cc
   a.cc: In instantiation of `Capsule<void ()(int)>':
   a.cc:3:   instantiated from `encapsulate<void ()(int)>(void (&)(int))'
   a.cc:10:   instantiated from here
   a.cc:1: field `Capsule<void ()(int)>::t' invalidly declared function type  
                                 ^^^^^^^^^^^^
Note that the template type of the Capsule class for the second
(template function) is a reference to a function rather than a
pointer. With gcc3.0.1 and SS20011107, the error message is again
rather unhelpful: 
   examples/step-1> ~/bin/gcc-3.0.1/bin/c++ -c a.cc
   a.cc: In function `void foo()':
   a.cc:10: no matching function for call to `encapsulate(<unknown type>)'

Release:
unknown

Environment:
2.95.2 and 3.0.1 and SS20011107
checked on Sun and Linux
Comment 1 Nathan Sidwell 2002-04-26 05:30:14 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: confirmed
Comment 2 nyap 2002-04-29 17:14:30 UTC
From: Noel Yap <nyap@OLF.COM>
To: "'wolfgang.bangerth@iwr.uni-heidelberg.de'"
	 <wolfgang.bangerth@iwr.uni-heidelberg.de>,
   "'gcc-gnats@gcc.gnu.org'"
	 <gcc-gnats@gcc.gnu.org>,
   "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
   "'nobody@gcc.gnu.org'"
	 <nobody@gcc.gnu.org>
Cc:  
Subject: Re: c++/5296: Pointers to functions and template functions behave
	 differentl
Date: Mon, 29 Apr 2002 17:14:30 -0400

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 <HTML>
 <HEAD>
 <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
 charset=3Diso-8859-1">
 <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 5.5.2653.12">
 <TITLE>Re: c++/5296: Pointers to functions and template functions =
 behave differentl</TITLE>
 </HEAD>
 <BODY>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial"><A =
 HREF=3D"http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&=
 database=3Dgcc&pr=3D5296" =
 TARGET=3D"_blank">http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20au=
 dit-trail&database=3Dgcc&pr=3D5296</A></FONT>
 </P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">I've found one or two (depending on if =
 you count them to be the same or not) workarounds for this:</FONT>
 <BR><FONT SIZE=3D2 FACE=3D"Arial">1. original snippet:</FONT>
 <BR><FONT FACE=3D"Courier New">int main () {<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (&amp;pp1);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (&amp;pp2&lt;int&gt;);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0};</FONT><FONT FACE=3D"Arial"> </FONT>
 </P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">workaround (note that reinterpret_cast =
 will NOT work here):</FONT>
 <BR><FONT FACE=3D"Courier New">int main () {<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (&amp;pp1);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type ((void (*)(int)) &amp;pp2&lt;int&gt;);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0};</FONT><FONT FACE=3D"Arial"> </FONT>
 </P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">2. original snippet:</FONT>
 <BR><FONT FACE=3D"Courier New">int main () {<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (&amp;pp1);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (&amp;pp2&lt;int&gt;);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0};</FONT><FONT FACE=3D"Arial"> </FONT>
 </P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">workaround:</FONT>
 <BR><FONT FACE=3D"Courier New">int main () {</FONT>
 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT FACE=3D"Courier =
 New">void (*pp2p)(int) =3D &amp;pp2&lt;int&gt;;</FONT>
 <BR>
 <BR><FONT FACE=3D"Courier New">=A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0 print_type (&amp;pp1);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0 print_type (pp2p);<BR>
 =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =A0&nbsp; =
 =A0};</FONT><FONT FACE=3D"Arial"> </FONT>
 </P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">I think the fact that reinterpret_cast =
 has problems points to the fact that the compiler really doesn't know =
 what the type is (and hence, the {unknown_type} in the error =
 message).</FONT></P>
 
 <P><FONT SIZE=3D2 FACE=3D"Arial">Noel Yap</FONT>
 </P>
 <BR>
 
 <P><B><FONT SIZE=3D2 FACE=3D"Arial">=A9 2002 OpenLink Financial =
 </FONT></B>
 </P>
 
 <P><B><FONT SIZE=3D2 FACE=3D"Arial">Copyright in this message and any =
 attachments remains with us.&nbsp; It is</FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">confidential and may be legally =
 privileged.&nbsp;&nbsp; If this message is not </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">intended for you it must not be =
 read, copied or used by you or </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">disclosed to anyone =
 else.&nbsp;&nbsp; Please advise the sender immediately if </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">you have received this message in =
 error.</FONT></B>
 </P>
 
 <P><B><FONT SIZE=3D2 FACE=3D"Arial">Although this message and any =
 attachments are believed to be free of </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">any virus or other defect that =
 might affect any computer system into </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">which it is received and opened, =
 it is the responsibility of the </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">recipient to ensure that it is =
 virus free and no responsibility </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">is accepted by Open Link =
 Financial, Inc. for any loss or damage in any </FONT></B>
 <BR><B><FONT SIZE=3D2 FACE=3D"Arial">way arising from its =
 use.</FONT></B>
 </P>
 <BR>
 
 </BODY>
 </HTML>
Comment 3 Andrew Pinski 2003-08-03 15:19:03 UTC
This is 3.3/3.4 regression as 2.95.2 accepted this code (but it produced wrong code).
Comment 4 Mark Mitchell 2003-09-08 07:25:38 UTC
This code is invalid.  A template argument cannot be deduced from a set of
overloaded functions if the set includes a template.
Comment 5 Mark Mitchell 2003-09-08 07:28:58 UTC
I take it back; obviously, that's why DR 115 was in the headline.
Comment 6 CVS Commits 2003-09-08 16:53:12 UTC
Subject: Bug 5296

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-09-08 16:53:05

Modified files:
	gcc/cp         : ChangeLog pt.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/rtti: typeid2.C 

Log message:
	PR c++/5296
	* pt.c (try_one_overload): Add addr_p parameter.
	(resolve_overloaded_unification): Pass it.
	
	PR c++/5296
	* g++.dg/rtti/typeid2.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3659&r2=1.3660
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.776&r2=1.777
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3040&r2=1.3041
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/rtti/typeid2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 7 CVS Commits 2003-09-08 16:59:05 UTC
Subject: Bug 5296

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	mmitchel@gcc.gnu.org	2003-09-08 16:59:00

Modified files:
	gcc/cp         : pt.c 
Added files:
	gcc/testsuite/g++.dg/rtti: typeid2.C 

Log message:
	PR c++/5296
	* pt.c (try_one_overload): Add addr_p parameter.
	(resolve_overloaded_unification): Pass it.
	
	PR c++/5296
	* g++.dg/rtti/typeid2.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.635.2.36&r2=1.635.2.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/rtti/typeid2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1

Comment 8 CVS Commits 2003-09-08 16:59:49 UTC
Subject: Bug 5296

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	mmitchel@gcc.gnu.org	2003-09-08 16:59:43

Modified files:
	gcc/cp         : ChangeLog 
	gcc/testsuite  : ChangeLog 

Log message:
	PR c++/5296
	* pt.c (try_one_overload): Add addr_p parameter.
	(resolve_overloaded_unification): Pass it.
	
	PR c++/5296
	* g++.dg/rtti/typeid2.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.202&r2=1.3076.2.203
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.274&r2=1.2261.2.275

Comment 9 Mark Mitchell 2003-09-08 17:01:58 UTC
Fixed in GCC 3.3.2, GCC 3.4.