[Bug c++/17501] New: Failing to compile code using boost bind/signal

[Bug c++/17501] New: Failing to compile code using boost bind/signal

[larsbj at gullik dot net]

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.

-- 
           Summary: Failing to compile code using boost bind/signal
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: larsbj at gullik dot net
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-15 15:22 -------
Yes, please. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[larsbj at gullik dot net]

------- Additional Comments From larsbj at gullik dot net  2004-09-15 16:15 -------
Created an attachment (id=7139)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7139&action=view)
Preprosessed source of code in initial posting.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-16 07:39 -------
I think this comes down to const references and such but I could be wrong.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[larsbj at gullik dot net]

------- Additional Comments From larsbj at gullik dot net  2004-09-16 07:55 -------
Ad. #3
Possibly, but note that this compiled with 3.4.1.
It has also compiled with eaerlier releases of mainline. (august)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 13:19 -------
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. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[larsbj at gullik dot net]

------- Additional Comments From larsbj at gullik dot net  2004-09-16 13:32 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 13:58 -------
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. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 14:08 -------
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. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 14:35 -------
Created an attachment (id=7152)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7152&action=view)
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] Failing to compile code using boost bind/signal

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 14:46 -------
Created an attachment (id=7153)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7153&action=view)
Testcase of 13kloc

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

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #7139 is|0                           |1
           obsolete|                            |
Attachment #7152 is|0                           |1
           obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 15:01 -------
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. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |rejects-valid
      Known to fail|                            |3.4.3 4.0.0
      Known to work|                            |3.4.2
   Last reconfirmed|0000-00-00 00:00:00         |2004-09-16 15:01:46
               date|                            |
            Summary|Failing to compile code     |[3.4/4.0 regression]
                   |using boost bind/signal     |Confusion with member
                   |                            |templates
   Target Milestone|---                         |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 15:03 -------
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. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-09-16 15:36 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[reichelt at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |critical
           Keywords|                            |monitored


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-16 17:49 -------
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. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-09-16 22:55 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-09-16 22:57 -------
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



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-09-16 23:00 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[bangerth at dealii dot org]

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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-09-17 01:56 -------
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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501

[Bug c++/17501] [3.4/4.0 regression] Confusion with member templates

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-09-17 03:12 -------
Oh, I'm sorry -- missed that, just looked at the committed testcase. 
Thanks a lot for the real quick fix! 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17501