[Bug c++/16174] [3.4/3.5 Regression] deducing top-level consts

["giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From giovannibajo at libero dot it  2004-06-25 13:14 -------
It looks like GCC deduction and SFINAE works correctly for the overloaded 
template function. The problem is elsewhere.

It seems that the problem is here:

      if (convs->check_copy_constructor_p)
	/* Generate a temporary copy purely to generate the required
	   diagnostics.  */
	build_temp
	  (build_dummy_object
	   (build_qualified_type (totype, TYPE_QUAL_CONST)),
	   totype, LOOKUP_NORMAL|LOOKUP_ONLYCONVERTING, &diagnostic_fn);

This is where a temporary is generated and discarded, for the purpose of access 
checking of the copy constructor (it's the new check that GCC 3.4 does).

In the testcase of this PR, GCC correctly deduces U=K<int> and rejects the 
template overload with SFINAE. Then, it decides that K(K<T> const&) is the 
right overload, but to bind the rvalue "K<int>()" to it, it needs to do create 
a temporary and use the cctor to fill it (actually, the temporary is then 
discarded, but still the cctor access check must be done).

The point is that this temporary is created with a top-level const qualifier 
(as can be seen in the code above). Thus, when reiterating cctor overload 
resolution, this time with a CONST LVALUE (such is what build_dummy_object 
returns), the K(U& rhs, ...) declaration is instantiated, and the trick works: 
it rejects initialization of the class from a const object.

Now, the question is why the dummy object is created with that top-level const 
qualifier (through build_qualified_type). This was introduced here: 
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00534.html (testcases in 
g++.dg/overload/ref1.C). Mark suggested a different resolution which looks more 
correct at first sight, but if implemented actually make GCC enter an infinite 
loop. They discussed the patch off-list and eventually it went in as-is.

It looks like putting the const there is wrong through. There must be another 
solution.

-- 


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