From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32075 invoked by alias); 6 Aug 2003 14:51:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 32064 invoked by uid 48); 6 Aug 2003 14:51:24 -0000 Date: Wed, 06 Aug 2003 14:51:00 -0000 From: "bangerth at dealii dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20030806145118.11834.bangerth@dealii.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/11834] New: [3.4 regression] template specialization not matched X-Bugzilla-Reason: CC X-SW-Source: 2003-08/txt/msg00899.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11834 Summary: [3.4 regression] template specialization not matched Product: gcc Version: 3.4 Status: UNCONFIRMED Severity: critical Priority: P1 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org CC: gcc-bugs at gcc dot gnu dot org Here's something I extracted from boost, and which breaks my nightly builds: --------------------------------- template struct tuple { typedef tuple tail; }; template <> struct tuple {}; template struct length { static const int i = length::i; }; template<> struct length > { static const int i = 0; }; template ::i> struct M {}; template M > foo (void (C::*)(A)); template M > foo (void (C::*)(A) const); struct S { void f(int) const; }; void bar() { foo (&S::f); } ---------------------------------------- g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c y.cc -ftemplate-depth-4 y.cc: In instantiation of `length::tail::tail::tail>': y.cc:9: instantiated from `length::tail::tail>' y.cc:9: instantiated from `length::tail>' y.cc:9: instantiated from `length >' y.cc:31: instantiated from here y.cc:9: error: incomplete type `length::tail::tail::tail::tail>' used in nested name specifier (Note that one should limit the template depth to avoid excessive screen clutter and keep computing time reasonable.) The error is entirely spurious: the return type of foo is M,1>, where the second template argument of M is deduced using length >::i, which should use the specialization of length. Even if it didn't, then the recusion should hit the specialization in the next round, but it doesn't. Note that the bug goes mysteriously away if I remove either of the two foo() functions. That doesn't make much sense, since only the second one should match the call in bar() anyway, but that's another bug which I reported a long time ago, see PR 8271. W.