gcc 3.4 snapshots currently have problems compiling packages like cppunit. I just checked snapshot 3.4.0 20040303 (prerelease) and this problem is still there. Here's a simplified example of the problem, I hope this i helpful. // test code class TestFailure { private: TestFailure(const TestFailure &); public: TestFailure(int *p); }; void dummy(const TestFailure &failure); void usingfunc(int *intp) { // this: { TestFailure foo(intp); dummy(foo); } // should be the same as this dummy( TestFailure(intp) ); } produces this error: t.cpp: In function `void usingfunc(int*)': t.cpp:5: error: `TestFailure::TestFailure(const TestFailure&)' is private t.cpp:18: error: within this context Full output from gcc -v -c t.cpp: Reading specs from /snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4.0/specs Configured with: ./configure --prefix=/snapshot Thread model: posix gcc version 3.4.0 20040303 (prerelease) /snapshot/libexec/gcc/i386-unknown-freebsd4.9/3.4.0/cc1plus -quiet -v t.cpp -quiet -dumpbase t.cpp -auxbase t -version -o /var/tmp//ccuJ8mOU.s ignoring nonexistent directory "/snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4. 0/../../../../i386-unknown-freebsd4.9/include" #include "..." search starts here: #include <...> search starts here: /snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4.0/../../../../include/c++/3.4.0 /snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4.0/../../../../include/c++/3.4. 0/i386-unknown-freebsd4.9 /snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4.0/../../../../include/c++/3.4. 0/backward /usr/local/include /snapshot/include /snapshot/lib/gcc/i386-unknown-freebsd4.9/3.4.0/include /usr/include End of search list. GNU C++ version 3.4.0 20040303 (prerelease) (i386-unknown-freebsd4.9) compiled by GNU C version 2.95.4 20020320 [FreeBSD]. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130534 t.cpp: In function `void usingfunc(int*)': t.cpp:5: error: `TestFailure::TestFailure(const TestFailure&)' is private t.cpp:18: error: within this context
No: "TestFailure(intp)" is an rvalue ([basic.lval]/6, or [expr.type.conv]/1), and binding a rvalue to a reference requires the construction of a temporary ([class.temporary]/1). When doing so, a copy constructor might be invoked. The standard (again at [class.temporary]/1) says that the copy can be elided, but the semantic restrictions (involving accessibility) must be satisfied. Hence GCC is correct here.
Reopening to mark as a dup of ...
bug 12226. *** This bug has been marked as a duplicate of 12226 ***