User account creation filtered due to spam.

Bug 17501 - [3.4/4.0 regression] Confusion with member templates
Summary: [3.4/4.0 regression] Confusion with member templates
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P2 critical
Target Milestone: 3.4.3
Assignee: Not yet assigned to anyone
URL:
Keywords: monitored, rejects-valid
Depends on:
Blocks:
 
Reported: 2004-09-15 15:04 UTC by Lars Gullik Bjønnes
Modified: 2004-09-17 03:12 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target:
Build:
Known to work: 3.4.2
Known to fail: 3.4.3 4.0.0
Last reconfirmed: 2004-09-16 15:01:46


Attachments
Preprosessed source of code in initial posting. (150.25 KB, application/x-tar)
2004-09-15 16:15 UTC, Lars Gullik Bjønnes
Details
slightly cleaned up sources (135.91 KB, application/x-gzip)
2004-09-16 14:35 UTC, Wolfgang Bangerth
Details
Testcase of 13kloc (36.63 KB, application/x-gzip)
2004-09-16 14:46 UTC, Wolfgang Bangerth
Details

Note You need to log in before you can comment on or make changes to this bug.
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<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.
Comment 1 Wolfgang Bangerth 2004-09-15 15:22:20 UTC
Yes, please. 
Comment 2 Lars Gullik Bjønnes 2004-09-15 16:15:56 UTC
Created attachment 7139 [details]
Preprosessed source of code in initial posting.
Comment 3 Andrew 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 
        * 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. 
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. 
 
W. 
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<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. 
 
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...

W.
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<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. 
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 
	* 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. 
Comment 13 Volker Reichelt 2004-09-16 15:36:18 UTC
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
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. 
 
W. 
Comment 15 CVS Commits 2004-09-16 22:55:21 UTC
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

Comment 16 CVS Commits 2004-09-16 22:57:05 UTC
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

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... 
 
W. 
Comment 19 Mark Mitchell 2004-09-17 01:56:14 UTC
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.

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