Variadic template as template parameter: deduction

While compiling some C++11 code with both GCC 4.7.2 and Clang 3.1, I ran into a problem with Clang not managing to deduce a template argument where GCC succeeds. In a more abstract form, the code looks like this:

src/test.cc:

struct Element {
};

template <typename T>
struct FirstContainer {
};

template <typename T, typename U = Element>
struct SecondContainer {
};

template <template <typename> class Container>
void processOrdinary(Container<Element> /*elements*/) {
}

template <template <typename, typename> class Container>
void processOrdinary(Container<Element, Element> /*elements*/) {
}

template <template <typename, typename...> class Container>
void processVariadic(Container<Element> /*elements*/) {
}

int main() {
  // This function instantiation works in both GCC and Clang.
  processOrdinary(FirstContainer<Element>{});
  // This function instantiation works in both GCC and Clang.
  processOrdinary(SecondContainer<Element>{});
  // This function instantiation works in both GCC and Clang.
  processVariadic(FirstContainer<Element>{});
  // This function instantiation works in both GCC and Clang.
  processVariadic<SecondContainer>(SecondContainer<Element>{});
  // This function instantiation works in GCC but not in Clang.
  processVariadic(SecondContainer<Element>{});
  return 0;
}

From reading the examples in §14.3.3 and the specifications in §14.8.2 of the standard I think the deduction should work, but I can not say for sure. This is the output I get from building:

mkdir -p build-gcc/
g++ -std=c++0x -W -Wall -Wextra -Weffc++ -pedantic -c -o build-gcc/test.o src/test.cc
g++  -o build-gcc/test build-gcc/test.o
mkdir -p build-clang/
clang++ -std=c++11 -Weverything -Wno-c++98-compat -c -o build-clang/test.o src/test.cc
src/test.cc:34:3: error: no matching function for call to 'processVariadic'
  processVariadic(SecondContainer<Element>{});
  ^~~~~~~~~~~~~~~
src/test.cc:21:6: note: candidate template ignored: failed template argument deduction
void processVariadic(Container<Element> /*elements*/) {
     ^
1 error generated.
make: *** [build-clang/test.o] Fel 1

Why do the results differ? Is GCC sloppy, Clang dumb, does my code contain unspecified behavior or all of them?

Clang is trying to deduce the arguments for this call:

processVariadic(SecondContainer<Element>{});

Since SecondContainer has a default template argument, this is equivalent to:

processVariadic(SecondContainer<Element, Element>{});

Thus, it performs template argument deduction with P = Container<Element> and A = SecondContainer<Element, Element>. It can immediately deduce that the Container template parameter is SecondContainer.

Next, it considers the template arguments. Since the argument type is fully resolved, Clang believes that the parameter must have as many types, or deduction cannot possibly succeed (it doesn't take default arguments into account). So it flags a deduction failure.

So, what's supposed to happen? In the words of [temp.deduct.type]p8,

A template type argument T, a template template argument TT or a template non-type argument i can be deduced if P and A have one of the following forms:
[...]
TT<T>
TT<i>
TT<>
where [...] <T> represents template argument lists where at least one argument contains a T, <i> represents template argument lists where at least one argument contains an i and <> represents template argument lists where no argument contains a T or an i.

In order to match the template arguments, we turn to [temp.deduct.type]p9:

If P has a form that contains <T> or <i>, then each argument Pi of the respective template argument list P is compared with the corresponding argument Ai of the corresponding template argument list of A.

There are two things to observe here. One is that this rule does not say what happens if the list Pi and Ai are different lengths (as they are in this case), and the common interpretation seems to be that the mismatched items are not examined. The other is that this rule should not be followed anyway, since the form of P does not contain <T> or <i> (it just contains <>, because there are no template parameters in it).

So, Clang was wrong to reject this code. I've fixed it in r169475.