Bug 10574 - Partial specialization selection failure involving a default template parameter from inside a template
Summary: Partial specialization selection failure involving a default template paramet...
Status: RESOLVED DUPLICATE of bug 14032
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: monitored, rejects-valid
Depends on:
Reported: 2003-04-30 23:46 UTC by Eelis
Modified: 2007-09-15 15:35 UTC (History)
16 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2006-09-03 21:39:22


Note You need to log in before you can comment on or make changes to this bug.
Description Eelis 2003-04-30 23:46:00 UTC
Consider the following code:

  template <typename>
  struct A
    struct B {};

    template <typename, typename T = B>
    struct C
      typename T::x y;

    template <typename T>
    struct C<T, B> {};

  A<int>::C<int> t;

The last statement should instantiate C's partial specialization. However, the nonspecialized version is instantiated, resulting in a compiler error:

  no type named `x' in `struct A<int>::B

When considering the specialization, it seems G++ fails to identify the automatically selected default parameter and the formal parameter of the specialization as the same B. Moving B outside A resolves the issue.

Comeau compiles the code without problems.

This problem seems to be related to PR9737, which was suspended due to possible change in the next version of the C++ standard. I think this problem is different enough for examination, especially since the current patch for 9737 does not cover this issue (it deals with template template parameter problems).

gcc version 3.2.2

Configured with: ../gcc-3.2.2/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i386-slackware-linux --host=i386-slackware-linux
Thread model: posix

Try compiling the code from the description.
Comment 1 Eelis 2003-04-30 23:46:00 UTC
No idea.
Comment 2 Giovanni Bajo 2003-05-01 00:12:19 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed on every GCC up to mainline 20030430.
Comment 3 Kriang Lerdsuwanakij 2004-07-30 17:34:49 UTC
Related to PR4882, PR13088.
Comment 4 Kriang Lerdsuwanakij 2004-11-28 10:46:38 UTC
Work postponed to GCC 4.1.  This bug is tricky to fix.
Comment 5 Kriang Lerdsuwanakij 2005-10-22 13:56:31 UTC
Won't work on it for a long while.
Comment 6 Volker Reichelt 2007-09-15 15:35:44 UTC
Fixed with the patch for PR 14032.

*** This bug has been marked as a duplicate of 14032 ***