17501 – [3.4/4.0 regression] Confusion with member templates (original) (raw)

Description Lars Gullik Bjønnes 2004-09-15 15:04:54 UTC

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::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 > >&, 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 > >] ../../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 > >]

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.

Comment 1 Wolfgang Bangerth 2004-09-15 15:22:20 UTC

Yes, please.

Comment 3 Drea Pinski 2004-09-16 07:39:51 UTC

I think this comes down to const references and such but I could be wrong.

Comment 4 Lars Gullik Bjønnes 2004-09-16 07:55:00 UTC

Ad. #3 Possibly, but note that this compiled with 3.4.1. It has also compiled with eaerlier releases of mainline. (august)

Comment 5 Wolfgang Bangerth 2004-09-16 13:19:02 UTC

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](show%5Fbug.cgi?id=16254 "RESOLVED FIXED - [4.0 Regression] ICE in lower_stmt, at gimple-low.c:205") 
    * 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.

Comment 6 Lars Gullik Bjønnes 2004-09-16 13:32:47 UTC

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.

Comment 7 Wolfgang Bangerth 2004-09-16 13:58:00 UTC

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.

Comment 8 Wolfgang Bangerth 2004-09-16 14:08:41 UTC

I probably need some help from people knowing boost::signals better than me:

There are three overloads of the get_inspectable_slot function: template 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.

Comment 9 Wolfgang Bangerth 2004-09-16 14:35:52 UTC

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...

Comment 10 Wolfgang Bangerth 2004-09-16 14:46:35 UTC

Created attachment 7153 [details] Testcase of 13kloc

Attached testcase shows the problem with IF pretty clearly, I guess.

Comment 11 Wolfgang Bangerth 2004-09-16 15:01:44 UTC

Here's my final testcase:

struct S { template struct Result { typedef int type; }; }; template struct F; template<> struct F { typedef S type; }; template struct IF { typedef typename F::type select; typedef typename select::template Result::type type; }; template struct IF;

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.)

Comment 12 Wolfgang Bangerth 2004-09-16 15:03:37 UTC

Looking at the ChangeLog, it most likely is this patch:

2004-09-13 Mark Mitchell <mark@codesourcery.com>

[PR c++/16162](show%5Fbug.cgi?id=16162 "RESOLVED FIXED - [3.4 regression] Rejects valid member-template-definition") 
* 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.

Comment 13 Volker Reichelt 2004-09-16 15:36:18 UTC

Here's something slightly simpler:

================================= template struct A;

template<> struct A<0> { struct B { struct C { typedef int D; }; }; };

template struct E { typename A::B::C::D i; };

Compiling this I get the error message:

x.cc:16: error: #typename_type' not supported by dump_decl#::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

Comment 14 Wolfgang Bangerth 2004-09-16 17:49:07 UTC

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.

Comment 17 Mark Mitchell 2004-09-16 23:00:14 UTC

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.

Comment 18 Wolfgang Bangerth 2004-09-17 00:21:34 UTC

Mark, did this fix both Volker's and my testcase (comments 11 and 13)? They had quite different error messages...

Comment 20 Wolfgang Bangerth 2004-09-17 03:12:08 UTC

Oh, I'm sorry -- missed that, just looked at the committed testcase. Thanks a lot for the real quick fix!