C++ PATCH for c++/35773

[Laurent GUERBY]

Hi Jason,

My compile farm auto tester failed to bootstrap 4.3 and
it seems to be a file you changed in your latest patch.

2008-04-17  Jason Merrill  <jason@redhat.com>

        PR c++/35773
        * call.c (build_user_type_conversion_1): Represent second step
of
        copy-init with an rvalue conversion.
        (convert_like_real) [ck_user]: Don't implicitly add it here.

Laurent

Thu Apr 17 18:18:31 CEST 2008
===X UPDATE === Thu Apr 17 18:18:31 CEST 2008
Updating SVN tree
U    gcc/ChangeLog
U    gcc/testsuite/ChangeLog
A    gcc/testsuite/g++.dg/overload/autoptr1.C
U    gcc/cp/call.c
U    gcc/cp/ChangeLog
U    gcc/config/rs6000/rs6000.c
Updated to revision 134399.
...
/home/guerby/build43/./prev-gcc/xgcc -B/home/guerby/build43/./prev-gcc/
-B/n/01/guerby/install-4.3/i686-pc-linux-gnu/bin/   -g -O2
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototype\
s -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings    -DHAVE_CONFIG_H  -o f951 \
        fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o
fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o
fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/i\
o.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o
fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o
fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/sim\
plify.o fortran/st.o fortran/symbol.o fortran/target-memory.o
fortran/convert.o fortran/dependency.o fortran/f95-lang.o
fortran/trans.o fortran/trans-array.o fortran/trans-common.o
fortran/trans-const.o for\
tran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o
fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o
fortran/trans-types.o main.o
libbackend.a ../libcpp/libcpp.a ../libdecnumber/\
libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -L/opt/cfarm/mpfr-2.3.1/lib -lmpfr -lgmp
cp/call.o: In function `build_user_type_conversion_1':
../../gcc-4_3-branch/gcc/cp/call.c:2713: undefined reference to
`MAYBE_CLASS_TYPE_P'
collect2: ld returned 1 exit status
make[3]: *** [cc1plus-dummy] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod
gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gfortran.pod
gcc.pod
make[3]: Leaving directory `/home/guerby/build43/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/guerby/build43'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build43'
make: *** [bootstrap] Error 2
Thu Apr 17 19:58:09 CEST 2008


On Thu, 2008-04-17 at 10:00 -0400, Jason Merrill wrote:
> This turns out to have been a wrong-code bug before that we just hadn't 
> noticed yet: before 4.3, for the call to f we do
> 
> operator auto_ptr&
> auto_ptr(auto_ptr&)
> operator auto_ptr_ref
> auto_ptr(auto_ptr_ref)
> 
> Which is invalid.  My previous patch caused us to (correctly) refuse to 
> call the operator auto_ptr_ref in order to satisfy the auto_ptr_ref 
> constructor.  But we shouldn't be calling a constructor twice in the 
> first place.  This turns out to have been caused by us first doing a 
> build_temp as part of the user-defined conversion, and then again for an 
> rvalue conversion added because the initial conversion op returns a 
> reference.
> 
> Fixed by always representing the second step of class 
> copy-initialization with an rvalue conversion, rather than when we 
> expand a user-defined conversion.
> 
> Tested x86_64-pc-linux-gnu, applied to trunk and 4.3.
>