Error in passing a function pointer as a const reference

["Matt Austern" <austern at isolde dot engr dot sgi dot com>]

This bug appears in recent versions of the egcs C++ front end.  Here is
a simple test case:

[austern@wotan2 tmp]$ cat ccbug.C
void f(int) {}

template <class F> void Apply(const F& f) {}

int main() {
  Apply(f);
}


This is legal: template argument deduction should yield
void (*)(int) as Apply's template argument type.  And, of
course, a const reference to a value of type void (*)(int)
is perfectly correct.

Here is the compiler output.
[austern@wotan2 tmp]$ g++ -v ccbug.C
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
 /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/cpp -lang-c++ -v -undef
-D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -D__ELF__ -Dunix
-Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__
-D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__EXCEPTIONS
-Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di586
-Dpentium -D__i586 -D__i586__ -D__pentium -D__pentium__ ccbug.C
/tmp/ccPZ4nMD.ii
GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/include
 /usr/include
End of search list.
 /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/cc1plus /tmp/ccPZ4nMD.ii
-quiet -dumpbase ccbug.cc -version -o /tmp/cccSHvrd.s
GNU C++ version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i586-pc-linux-gnu)
compiled by GNU C version egcs-2.91.60 19981201 (egcs-1.1.1 release).
ccbug.C: In function `int main()':
ccbug.C:6: converting to `void ()(int)' from `void (*)(int)'
ccbug.C:3: in passing argument 1 of `Apply<void ()(int)>(void ( &)(int))'


The error message makes no sense, since no conversions should be
performed on the argument.

This is a serious bug, because declaring the parameter to be passed
by const reference is the only way go guarantee that its copy constructor
(possibly an expensive operation in the case of a general function object)
is not called.

			--Matt Austern