Commit cdc30df3 by Dodji Seketeli Committed by Dodji Seketeli

PR c++/40942 - Failure of template specialization partial ordering

gcc/cp/

	* pt.c (more_specialized_fn):  Don't apply decay conversion to
	types of function parameters.

gcc/testsuite/

	* g++.old-deja/g++.pt/spec40.C: Adjust to take the resolution of
	DR 214 in account.

From-SVN: r186067
parent db435dce
2012-04-02 Dodji Seketeli <dodji@redhat.com>
PR c++/40942
* pt.c (more_specialized_fn): Don't apply decay conversion to
types of function parameters.
2012-04-02 Tristan Gingold <gingold@adacore.com>
* ggc-page.c (PAGE_L1_SIZE, PAGE_L2_SIZE, LOOKUP_L1, LOOKUP_L2)
......
......@@ -17132,46 +17132,6 @@ more_specialized_fn (tree pat1, tree pat2, int len)
quals2 = cp_type_quals (arg2);
}
if ((quals1 < 0) != (quals2 < 0))
{
/* Only of the args is a reference, see if we should apply
array/function pointer decay to it. This is not part of
DR214, but is, IMHO, consistent with the deduction rules
for the function call itself, and with our earlier
implementation of the underspecified partial ordering
rules. (nathan). */
if (quals1 >= 0)
{
switch (TREE_CODE (arg1))
{
case ARRAY_TYPE:
arg1 = TREE_TYPE (arg1);
/* FALLTHROUGH. */
case FUNCTION_TYPE:
arg1 = build_pointer_type (arg1);
break;
default:
break;
}
}
else
{
switch (TREE_CODE (arg2))
{
case ARRAY_TYPE:
arg2 = TREE_TYPE (arg2);
/* FALLTHROUGH. */
case FUNCTION_TYPE:
arg2 = build_pointer_type (arg2);
break;
default:
break;
}
}
}
arg1 = TYPE_MAIN_VARIANT (arg1);
arg2 = TYPE_MAIN_VARIANT (arg2);
......
2012-04-02 Dodji Seketeli <dodji@redhat.com>
PR c++/40942
* g++.old-deja/g++.pt/spec40.C: Adjust to take the resolution of
DR 214 in account.
2012-04-01 Paolo Carlini <paolo.carlini@oracle.com>
PR c++/50043
......
// { dg-do run }
// { dg-do compile }
// Copyright (C) 2000 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 12 Feb 2001 <nathan@codesourcery.com>
// More from bug 1617. We didn't resolve partial ordering properly. The
// std is rather vague about it anyway, DR 214 talks about this.
// More from bug 1617. The resolution of DR 214 implies that the below
// call to Foo is ambiguous.
//
// The type transformation (on the function parameter of Foo) allowed
// in the context of partial ordering of the Foo template overloads is
// the following ([temp.deduct.partial]/5):
//
// Before the partial ordering is done, certain transformations
// are performed on the types used for partial ordering:
//
// - If P is a reference type, P is replaced by the type
// referred to.
//
// - If A is a reference type, A is replaced by the type
// referred to.
//
// It follows that we are not allowed to apply array-to-pointer
// decay conversion to the type of the function parameter
// 'char const (&)[I]'. So the two Foo specializations should
// be considered unrelated. Thus the partial ordering of the two
// Foo specializations should fail.
template <typename T> int Foo (T const *) {return 1;}
template <unsigned I> int Foo (char const (&)[I]) {return 2;}
int main ()
{
return Foo ("a") != 2;
return Foo ("a") != 2; // { dg-error "call of overloaded \[^\n\r\]* is ambiguous" }
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment