Paolo Bonzini <bonz...@gnu.org> writes:
> On 08/03/2011 04:01 PM, Rainer Orth wrote:
>>> Configure tests could also make a better replacement for softfp_wrap_start
>>> and softfp_wrap_end.
>>
>> We've got two uses left right now:
>>
>> * libgcc/config/arm/t-softfp has #ifdef __ARM_ARCH_6M__. One could
>> probably use AC_EGREP_CPP([__ARM_ARCH_6M__], , [arm_arch_6m=true]) in
>> configure.ac instead, but this is completely untested.
>
> It would have to be something like this:
>
> AC_EGREP_CPP([win win win], [#ifdef __ARM_ARCH_6M__
> win win win
> #endif], [arm_arch_6m=true])
>
> However, this cannot be in config.host because that file is sourced rather
> than m4_included.
It was meant to go into configure.ac directly.
> Alternatively, we can make a list of desired symbols and test them in
> configure.ac:
>
> arm-*-*)
> ...
> libgcc_cpp_symbols="$libgcc_cpp_symbols __ARM_ARCH_6M__"
> tmake_file="$tm_file arm/t-softfp"
> ;;
>
> ...
>
> # in configure.ac:
> # Look for preprocessor symbols that can be useful
> cpp_symbols=
> if test -n "$libgcc_cpp_symbols"; then
> for i in $libgcc_cpp_symbols; do
> AC_EGREP_CPP([win win win], [#ifdef $i
> win win win
> #endif], [AS_VAR_APPEND([cpp_symbols], [ $i])])
> done
> fi
> AC_SUBST([cpp_symbols])
>
> ...
>
> # config/arm/t-softfp
> ifneq ($(filter __ARM_ARCH_6M__, $(cpp_symbols)),)
> include ../t-softfp-sfdf
> include ../t-softfp-excl
> include ../t-softfp
> endif
That looks like a very useful and general approach.
>> * libgcc/config/rs6000/t-linux64 has #ifndef __powerpc64__. Again, one
>> could either check for __powerpc64__ or perform a long_type_size check
>> along the double_type_size etc. checks in the fp-bit patch.
>
> Yes, that's better than using a preprocessor symbol in this case:
Ok.
>> I'm impartial about how to handle this, but would rather get the patch
>> in and perform cleanup later than delay even more.
>
> Agreed.
Fine, thanks. I'll work on the cleanups after I've beaten the whole
series in shape. Right now, I've got those:
* SHLIB_* is close.
* crtstuff.c and extra_parts need a look-over.
* LIB1* and LIB2*/LIBGCC2* likewise.
* Before TARGET_LIBGCC2_CFLAGS can be removed,
gcc/ada/gcc-interface/Makefile.in's use of it (which only needs
PICFLAG, AFAICT) needs changing. Right now, only three libraries may
be built PIC, but don't use libtool: libiberty, libgcc_s, and
libgnat/libgnarl. Since I very much doubt that moving them to use
libtool will get much traction, I suggest to at least centralize
configuration of PICFLAG (in toplevel config/picflag.m4). I've got an
initial patch for that, but need to merge the data from libiberty and
libgcc to complete it.
>> As the two others, bootstrapped without regressions on
>> x86_64-unknown-linux-gnu. Bootstraps on i386-pc-solaris2.10,
>> sparc-sun-solaris2.11, alpha-dec-osf5.1b, mips-sgi-irix6.5, and
>> i386-apple-darwin9.8.0 still running.
>>
>> Ok for mainline if they pass?
>
> Yes, thank you very much!
Thanks, both for the review and the helpful suggestions.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
