Hm, interesting. I would have thought as well that the code should compile.
On the other hand, icc also produces the same error message, so I am now
officially confused...

IIUC, the top-level const qualifier on "const typename Foo<D>::double3" in the primary template applies to the type, which is not known during phase 1

At instantiation time, double3 is known to be an array type, so decays to a pointer, and the parameter type becomes "const double*" _not_ "double* const"

So the explicit instantiation creates a type which does not match the primary template, so it cannot be a specialisation of it.

(In reply to comment #2)
> IIUC, the top-level const qualifier on "const typename Foo<D>::double3" in the
> primary template applies to the type, which is not known during phase 1

i.e. it's equivalent to "typename Foo<D>::double3 const" which is equivalent to simply "typename Foo<D>::double3) because top-level cv-qualifiers are removed from function parameters.
 
but when double3 is known to be an array type, which is replaced by a pointer in a parameter list, then the declaration's meaning changes.

Consider:

typedef double  double3[3];
void f(const double3);
typedef void (*ptr)(const double*);
ptr p = f;

This demonstrates that the declaration of 'f' is equivalent to:

void f(const double*);

not

void f(double* const);

According to [dcl.fct] array parameters are replaced with pointers before top-level cv-qualifiers are deleted.

I think GCC is correct, the template specializations are invalid.

Thanks Jonathan for your explanation. Now I can understand the reason behind this... (though I'm not really happy with the fact that you need to understand sort of internals to see why code doesn't compile). 

Do I need to mark the bug-report as invalid, or how does it work?

Thanks!

I think this is a bug; we shouldn't be dropping the const at template parsing time.

Actually, I'm not so sure:

template<class T>
struct A
{
  typedef A arr[3];
};

template<class T>
void f(const typename A<T>::arr) { }

template void f<int>(const A<int>::arr); // #1

template <class T>
struct B
{
  void g(T);
};

template <class T>
void B<T>::g(const T) { } // #2 

it seems to me that either #1 is well-formed, or #2 is, though it might make sense to recompute the function type from the parameter type...in any case, I'm opening a DR about this.

Created attachment 18996 [details]
patch

Here's a patch that fixes the testcase and passes regression testing, but I don't think it's the right way to go.

Jason, the extra const in the library code is definitely unintended, I'm going to remove it anyway.

Suspending until the committee can rule on this, but I expect the result to be that the testcase is ill-formed.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1001 is NAD so I think we can close this bug as INVALID

Agreed.