gcc-3_4-branch from 2004/03/11, 01:01am PST Configured with: /net/worm/scratch1/rwgk/gcc-3_4-branch/configure -- prefix=/usr/local_cci/gcc-3_4-branch_2004_03_11 --enable-languages=c,c++ Redhat Linux 8.0 Boost CVS from 2004/03/10, 13:06 PST % g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -ffast-math - DBOOST_PYTHON_MAX_BASES=2 -I/net/worm/scratch1/rwgk/hot/boost - I/usr/include/python2.2 - E /net/worm/scratch1/rwgk/hot/boost/libs/python/test/auto_ptr.cpp > auto_ptr_pp.cpp % g++ -fPIC -ftemplate-depth-120 -w -O3 -ffast-math -c auto_ptr_pp.cpp /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/invoke.hpp: In function `PyObject* boost::python::detail::invoke(boost::python::detail::invoke_tag_< false, false>, const RC&, F&, AC0&) [with RC = boost::python::to_python_value<const std::auto_ptr<X>&>, F = std::auto_ptr<X> (*)(boost::python::api::object), AC0 = boost::python::arg_from_python<boost::python::api::object>]': /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/caller.hpp:199: instantiated from `PyObject* boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = std::auto_ptr<X> (*) (boost::python::api::object), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<std::auto_ptr<X>, boost::python::api::object>]' /net/worm/scratch1/rwgk/hot/boost/boost/python/object/py_function.hpp:39: instantiated from `PyObject* boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<std::auto_ptr<X> (*) (boost::python::api::object), boost::python::default_call_policies, boost::mpl::vector2<std::auto_ptr<X>, boost::python::api::object> >]' /net/worm/scratch1/rwgk/hot/boost/libs/python/test/auto_ptr.cpp:90: instantiated from here /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/invoke.hpp:76: error: passing `const std::auto_ptr<X>' as `this' argument of `std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 = X, _Tp = X]' discards qualifiers /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/invoke.hpp: In function `PyObject* boost::python::detail::invoke(boost::python::detail::invoke_tag_< false, false>, const RC&, F&) [with RC = boost::python::to_python_value<const std::auto_ptr<X>&>, F = std::auto_ptr<X> (*)()]': /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/caller.hpp:199: instantiated from `PyObject* boost::python::detail::caller_arity<0u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = std::auto_ptr<X> (*) (), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector1<std::auto_ptr<X> >]' /net/worm/scratch1/rwgk/hot/boost/boost/python/object/py_function.hpp:39: instantiated from `PyObject* boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*, PyObject*) [with Caller = boost::python::detail::caller<std::auto_ptr<X> (*)(), boost::python::default_call_policies, boost::mpl::vector1<std::auto_ptr<X> > >]' /net/worm/scratch1/rwgk/hot/boost/libs/python/test/auto_ptr.cpp:90: instantiated from here /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/invoke.hpp:76: error: passing `const std::auto_ptr<X>' as `this' argument of `std::auto_ptr<_Tp>::operator std::auto_ptr_ref<_Tp1>() [with _Tp1 = X, _Tp = X]' discards qualifiers The same code compiles with g++ (GCC) 3.4.0 20040220(prerelease) and many other compilers. I will attach the preprocessed source code. The same file is also available here: http://cci.lbl.gov/~rwgk/bugs/gcc340/auto_ptr_pp.cpp.gz
Created attachment 5898 [details] Preprocessed source, gzipped
I do not know if this is valid code, to me the error looks corrects but I did not follow through the steps of the error. It worked in 3.5.0 (20040304) but not in 3.5.0 (20040311). The two patch which might cause this is: 2004-03-10 Mark Mitchell <mark@codesourcery.com> PR c++/14510 * decl.c (xref_tag): Disregard non-type declarations when looking up a tagged type. 2004-03-09 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14409 * pt.c (determine_specialization): For member templates, match also constness.
It still worked on 20040307 on both 3.4 and mainline. W.
Andrew's guesses were wrong, the error actually appeared with Nathan's patch for PR 14397: http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00456.html (3.4-branch) http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00458.html (mainline)
We need a redux for this, anybody can help? I don't have time in these days.
The problem is basically an auto_ptr problem which can be demonstrated with the following code snippet: ============================================================================== #include<memory> typedef const std::auto_ptr<int> A; void foo(const A&); A makeA(); void bar() { A a; foo(a); // OK foo(A()); // error foo(makeA()); // error - the same as in line 45994 of the original example } ============================================================================== The problem is, that you need a copy for the temporary (which can be eliminated, but in theory you need it). With the current implementation of auto_ptr this is not supplied. I don't know whether this is correct or a flaw in our auto_ptr implementation, or even a flaw in the standard. (See PR 14254/3247 for a related issue that came up with stricter checking of the temporary.) Can a libstdc++ guru provide some insight, please?
ICC 6.0 gives: pr14528.cc(12): warning #377: class "std::auto_ptr<int>" has no suitable copy constructor foo(A()); // error ^ pr14528.cc(13): warning #377: class "std::auto_ptr<int>" has no suitable copy constructor foo(makeA()); // error - the same as in line 45994 of the original example ^
Yes, Andrew, same for Icc8 (but only in -strict_ansi mode)
(In reply to comment #2) > I do not know if this is valid code, to me the error looks corrects When I saw this response I alerted David Abrahams (major author of boost) to this PR. He had a close look at the issue and came to the conclusion that the latest gcc 3.4 is right! He wasn't forthcoming with details leading to the conclusion, but the most recent boost CVS is already patched to eliminate the error. Sorry that we didn't catch this earlier; however it is quite unusual to see a new but correct error message for code that compiles with so many other compilers, including gcc 3.4 from 10 days ago.
The point is that we generate a temporary for which the standard prescribes that a copy constructor must be accessible. We do not have to use it, and in fact don't and never did, and as it seems other compilers don't as well. However, the compiler needs to still check that the copy constructor is in fact accessible, something that we have apparently not done up to now. In other words, the change in the compiler will not lead to different code for valid programs, we just check a few more things. In this case boost got tripped by that. W.