The following code compiles with gcc 3.3.3 (RH Fedorea core 2 release), and also used to compile with gcc 3.4.x before 3.4.2 was released. Currently both gcc 3.4.3 and gcc 4.0.0 fail to compile this. This is with boost 1.31.0. Code: #include <boost/bind.hpp> #include <boost/signals/signal0.hpp> class Bar { public: static Bar const & cref() { static Bar bar; return bar; }; void update() const; }; typedef boost::signal0<void>::slot_type slot_type; boost::signals::connection connect(slot_type const &); void foo() { connect(boost::bind(&Bar::update, boost::cref(Bar::cref()))); } I compile with: g++ --save-temps -I../../boost -c test.C -o test.o Error message: ../../boost/boost/signals/slot.hpp: In constructor `boost::slot<SlotFunction>::slot(const F&) [with F = boost::_bi::bind_t<void, boost::_mfi::cmf0<void, Bar>, boost::_bi::list1<boost::reference_wrapper<const Bar> > >, SlotFunction = boost::function0<void, std::allocator<boost::function_base> >]': test.C:17: instantiated from here ../../boost/boost/signals/slot.hpp:108: error: no matching function for call to `get_inspectable_slot(const boost::_bi::bind_t<void, boost::_mfi::cmf0<void, Bar>, boost::_bi::list1<boost::reference_wrapper<const Bar> > >&, boost::signals::detail::reference_tag)' ../../boost/boost/signals/slot.hpp:71: note: candidates are: const F& boost::signals::get_inspectable_slot(const F&, boost::signals::detail::signal_tag) [with F = boost::_bi::bind_t<void, boost::_mfi::cmf0<void, Bar>, boost::_bi::list1<boost::reference_wrapper<const Bar> > >] ../../boost/boost/signals/slot.hpp:81: note: const F& boost::signals::get_inspectable_slot(const F&, boost::signals::detail::value_tag) [with F = boost::_bi::bind_t<void, boost::_mfi::cmf0<void, Bar>, boost::_bi::list1<boost::reference_wrapper<const Bar> > >] g++ --version g++ (GCC) 4.0.0 20040914 (experimental) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please tell if preprocessed source is needed.
Yes, please.
Created attachment 7139 [details] Preprosessed source of code in initial posting.
I think this comes down to const references and such but I could be wrong.
Ad. #3 Possibly, but note that this compiled with 3.4.1. It has also compiled with eaerlier releases of mainline. (august)
I can compile this with a mainline compiler from 20040913 without problems. The top of my ChangeLog file in gcc is 2004-09-13 Joseph S. Myers <jsm@polyomino.org.uk> * c-decl.c (grokdeclarator): Correct comments about where storage class specifiers are rejected by grammar and add corresponding asserts. Diagnose typedefs and parameters declared inline. Change warning for inline main to a pedwarn. Only diagnose inline main if hosted. (declspecs_add_scspec): Allow duplicate "inline". In gcc/cp, the top entry is 2004-09-12 Richard Henderson <rth@redhat.com> PR c++/16254 * semantics.c (maybe_cleanup_point_expr): Don't call fold. * typeck.c (condition_conversion): Likewise. Your compiler was from just one day later. Do you still have that tree and can say what the last patch for you was in both directories? It may be that we can pinpoint the problematic patch relatively easily this way. W.
The top of gcc/ChangeLog is: 2004-09-14 Jeff Law <law@redhat.com> * tree-ssa-dom.c (stmts_to_rescan): Move from a block-local to a global varray. (tree_ssa_dominator_optimize): Allocate stmts_to_rescan. (dom_opt_initialize_block_local_data): No longer test state of stmts_to_rescan. (dom_opt_finalize_block): Update due to change in scope of stmts_to_rescan. (optimize_stmt): Similarly. And the top of gcc/cp/ChangeLog is: 2004-09-14 Nathan Sidwell <nathan@codesourcery.com> * pt.c (unify): Replace gcc_unreachable with gcc_assert. Note that I see the same error with gcc 3.4.3 20040915.
I can confirm this with a CVS from right now. Will have to figure out whether this is a bug or whether the compiler just got stricter. W.
I probably need some help from people knowing boost::signals better than me: There are three overloads of the get_inspectable_slot function: template<typename F> const F& get_inspectable_slot(const F& f, signals::detail::signal_tag); template<typename F> const F& get_inspectable_slot(const reference_wrapper<F>& f, signals::detail::reference_tag); template<typename F> const F& get_inspectable_slot(const F& f, signals::detail::value_tag); The call that fails looks like this: signals::get_inspectable_slot(f, signals::tag_type(f)); where signals::tag_type(f) returns an object of type boost::signals::detail::reference_tag With that, it is clear that no overload matches. HOWEVER: with a gcc 3.4, signals::tag_type(f) returns an object of type boost::signals::detail::value_tag for which we have a matching overload. I should try next to figure out why this is so. W.
Created attachment 7152 [details] slightly cleaned up sources It turns out that the IF template isn't working properly. Attached is a very slightly cleaned-up version of the file. If in the function tag_type the template IF is replace by MY_IF, then the code compiles. Got to figure out then why IF isn't working... W.
Created attachment 7153 [details] Testcase of 13kloc Attached testcase shows the problem with IF pretty clearly, I guess.
Here's my final testcase: ----------------------- struct S { template<typename> struct Result { typedef int type; }; }; template<bool> struct F; template<> struct F<false> { typedef S type; }; template<bool Condition> struct IF { typedef typename F<Condition>::type select; typedef typename select::template Result<int>::type type; }; template struct IF<false>; ----------------------- g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c y.cc g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c y.cc y.cc:15: error: `type' in namespace `::' does not name a type It should compile, but doesn't. This is clearly a bug, and a regression on both mainline and the 3.4 branch. (The 3.4 branch compiler above hasn't been updated in a few days, while the mainline compiler is top of tree.) W.
Looking at the ChangeLog, it most likely is this patch: 2004-09-13 Mark Mitchell <mark@codesourcery.com> PR c++/16162 * parser.c (cp_parser_id_expression): Correct value for is_declarator. (cp_parser_nested_name_specifier_opt): Look through typenames as necessary. (cp_parser_template_name): Honor check_dependency_p. W.
Here's something slightly simpler: ================================= template<int> struct A; template<> struct A<0> { struct B { struct C { typedef int D; }; }; }; template<int I> struct E { typename A<I>::B::C::D i; }; ================================= Compiling this I get the error message: x.cc:16: error: `#`typename_type' not supported by dump_decl#<declaration error>::C' is not a class or namespace x.cc:16: error: expected nested-name-specifier before "D" x.cc:16: error: `D' does not name a type
I've had this weird error message as well, sometime in the middle, but wasn't sure whether it was the same problem. It sure sounds different. W.
Subject: Bug 17501 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2004-09-16 22:55:14 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: typename7.C Log message: PR c++/17501 * parser.c (cp_parser_nested_name_specifier): Do not resolve typename types if the user explicitly said "typename". PR c++/17501 * g++.dg/template/typename7.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4359&r2=1.4360 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.247&r2=1.248 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4301&r2=1.4302 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/typename7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 17501 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: mmitchel@gcc.gnu.org 2004-09-16 22:57:02 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: typename7.C Log message: PR c++/17501 * parser.c (cp_parser_nested_name_specifier): Do not resolve typename types if the user explicitly said "typename". PR c++/17501 * g++.dg/template/typename7.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.157&r2=1.3892.2.158 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.39&r2=1.157.2.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.268&r2=1.3389.2.269 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/typename7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
The test case fixes both the test case in comment #11 and the test case in comment #13. Fixed in GCC 3.4.3 and GCC 4.0.
Mark, did this fix both Volker's and my testcase (comments 11 and 13)? They had quite different error messages... W.
Subject: Re: [3.4/4.0 regression] Confusion with member templates bangerth at dealii dot org wrote: >------- Additional Comments From bangerth at dealii dot org 2004-09-17 00:21 ------- >Mark, did this fix both Volker's and my testcase (comments 11 and 13)? >They had quite different error messages... > > Yes, it did, and that's why I wrote: The test case fixes both the test case in comment #11 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501#c11> and the test case in comment #13 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501#c13>. in comment #17. I should have said "the patch" instead of "the test case" at the beginning of that sentence, though.
Oh, I'm sorry -- missed that, just looked at the committed testcase. Thanks a lot for the real quick fix! W.