[Bug c++/56506] New: variadic class template specialization not selected as best match

[Bug c++/56506] New: variadic class template specialization not selected as best match

[mmehlich at semanticdesigns dot com]

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

             Bug #: 56506
           Summary: variadic class template specialization not selected as
                    best match
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mmehlich@semanticdesigns.com


I'd expect the instantiation of X in the following code to resolve to
the partial specialization, but gcc 4.7.2 seems to instantiate the base
template (causing a compile-time name resolution error).

// Code:
template<typename ... T> struct X { };
template<typename ... T> struct Y { };
template<typename ... T> struct Z { };

template<typename ... T>  struct X<Y<Z<T...>,T>...> {
    typedef int type;
};

X<Y<Z<int,bool,char>,int>, 
  Y<Z<int,bool,char>,bool>, 
  Y<Z<int,bool,char>,char>>::type x;

// Detailed compiler version information:
gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enabl
e-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)

[Bug c++/56506] variadic class template specialization not selected as best match

[mmehlich at semanticdesigns dot com]

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

--- Comment #1 from Michael Mehlich <mmehlich at semanticdesigns dot com> 2013-03-02 18:55:43 UTC ---
Some more information using a function template instead of a class template:

-- Additional code
template<typename ... T> void foo(Y<Z<T...>,T>...) {
}

int main() {
    Y<Z<int,bool,char>,int> yi;
    Y<Z<int,bool,char>,bool> yb;
    Y<Z<int,bool,char>,char> yc;
    foo(yi,yb,yc);
}

-- Error message from gcc 4.7.2:
test.cpp: In function 'int main()':
test.cpp:31:14: error: no matching function for call to 'foo(Y<Z<int, bool,
char>, int>&, Y<Z<int, bool, char>, bool>&, Y<Z<int, bool, char>, char>&)'
test.cpp:31:14: note: candidate is:
test.cpp:15:31: note: template<class ... T> void foo(Y<Z<T ...>, T>...)
test.cpp:15:31: note:   template argument deduction/substitution failed:
test.cpp:31:14: note:   deduced conflicting types for parameter 'T' ('int,
bool, char' and 'int')
test.cpp:31:14: note:   'Y<Z<int, bool, char>, int>' is not derived from 'Y<Z<T
...>, T>'

It looks like the compiler decides to bind T to int when handling the
first argument instead of binding a "prefix" of T to int.

[Bug c++/56506] variadic class template specialization not selected as best match

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-03-03 19:46:42 UTC ---
I don't think that either example should be accepted. My understanding is, that
the second T is still considered as a parameter pack but not as an expansion
(because it is not followed by ...) at the time of pattern match checking,
therefore the compiler would try to match a sequence of expansions from the
first T... with a corresponding parameter pack. But this pack is always
considered as a different type, even if it would contain the same single type
(e.g. consider an argument type Y<Z<int>, int> where we would try to match
'int' with '[int]' where I use square brackets to denote the still existing
pack). So both cannot be the same type, and this specialization can never be
found. It would work, if you would declare the partial specialization as:

template<typename... T, typename... U>  
struct X<Y<Z<T...>, U>...> 
{
  typedef int type;
};

because now the compiler don't needs to cross-match corresponding T expansions
with the U pack.

I understand that this is a somewhat more generous specialization as you would
like to have, though.

[Bug c++/56506] variadic class template specialization not selected as best match

[mmehlich at semanticdesigns dot com]

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

--- Comment #3 from Michael Mehlich <mmehlich at semanticdesigns dot com> 2013-03-04 16:58:45 UTC ---
Considering that based on 14.5.3(5) a template member declaration
  X<Y<Z<T...>,T>...>::type x;
with T bound to int,bool,char must expand to
  X<Y<Z<int,bool,char>,int>, 
  Y<Z<int,bool,char>,bool>, 
  Y<Z<int,bool,char>,char>>::type x;
I'd consider it rather counter-intuitive if I cannot get a match as described
in my original message.

Does the standard actually specify how the matching process works in detail
in the presence of variadic templates?  Going through the template section,
I haven't found anything definite that would put light onto this issue
(though I might have missed it).

I can't really understand your "because it is not followed by ...";
after all, in X<Y<Z<T...>, U>...> the parameter pack U is also not immediately
followed by a ..., so why is that case ok but my original one isn't?

It is pretty easy to implement a matcher that successfully matches the case
in the original message, so I don't think the standard has any excuse not to
consider this a successful match, either.  
Notwithstanding that, the standards committee might have decided otherwise.
If so, where does it say so in the standard, resp. how can I conclude this
from what I can find in there?

--
  Michael

[Bug c++/56506] variadic class template specialization not selected as best match

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-03-05 20:18:00 UTC ---
(In reply to comment #3)
Presumably my judgment was a bit premature and I think there is a logical flaw
in my original argumentation: I think I misinterpreted 14.5.3 p5. I'm switching
to observer-mode, but your examples are quite interesting because every
compiler with variadic template support that I have access to rejects them.
This seems to indicate some possible unforeseen case in existing models. I have
forwarded this to the core language group.

[Bug c++/56506] variadic class template specialization not selected as best match

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-04-04
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-checking,
                   |                            |ice-on-valid-code

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. This ICEs on the trunk (but I don't think it is a regression as the
assert is a gcc_checking_assert).

The ICE:

<source>:12:28: internal compiler error: in comptypes, at cp/typeck.cc:1684
   12 |   Y<Z<int,bool,char>,char>>::type x;
      |                            ^~

[Bug c++/56506] variadic class template specialization not selected as best match

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Confirmed. This ICEs on the trunk (but I don't think it is a regression as
> the assert is a gcc_checking_assert).
> 
> The ICE:
> 
> <source>:12:28: internal compiler error: in comptypes, at cp/typeck.cc:1684
>    12 |   Y<Z<int,bool,char>,char>>::type x;
>       |                            ^~

I should note clang accepts the code.

[Bug c++/56506] variadic class template specialization not selected as best match

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> I should note clang accepts the code.

But EDG does not.
While MSVC accepts it.