On Thu, Jul 23, 2015 at 02:46:43PM +0200, Ulrich Weigand wrote:
> This is supposed to be fixed by this pending patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01546.html
LGTM.
> > The config.host change also looks wrong, e.g. i?86 or mips have:
> > i[34567]86-*-* \
> > | x86_64-*-* )
> > case ${target} in
> > i[34567]86-*-* \
> > | x86_64-*-* )
> > host_extra_gcc_objs="driver-i386.o"
> > host_xmake_file="${host_xmake_file} i386/x-i386"
> > ;;
> > esac
> > ;;
> > mips*-*-linux*)
> > case ${target} in
> > mips*-*-linux*)
> > host_extra_gcc_objs="driver-native.o"
> > host_xmake_file="${host_xmake_file} mips/x-native"
> > ;;
> > esac
> > ;;
> > while s390 has:
> > s390-*-* | s390x-*-*)
> > host_extra_gcc_objs="driver-native.o"
> > host_xmake_file="${host_xmake_file} s390/x-native"
> > ;;
> > I bet that is gone break also cross-compilers from s390* to other targets.
>
> I think this should be fine on s390. The problem with i386 is that
> the driver-native.c file uses data types only defined by the i386
> target files (e.g. enum processor_type). But on s390, the file does
> not any target-specific types and should be fully portable.
That hunk means that driver-native.o is added to EXTRA_GCC_OBJS
even say for s390x-*-* -> x86_64-*-* compiler. While it might compile
there, nothing will use it, so what is it good for?
i?86/x86_64 backend will certainly not reference s390_host_detect_local_cpu
anywhere.
Jakub
