This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Enable non-complex math builtins from C99 for Bionic


On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:

> Hi Maxim,
> 
> 2013/9/4 Maxim Kuvyrkov <maxim@kugelworks.com>:
>> On 23/08/2013, at 1:04 AM, Alexander Ivchenko wrote:
>> 
>>> Ugh.. thanks, you are right. That points to another problem that I
>>> didn't see before:
>>> 
>>> 3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and
>>> s390x-ibm-tpf* - your patch addresses that problem correctly) OR
>>> tmake_file (bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux*)
>> 
>> Could you be more verbose, please?  What some of the *linux* target do not append to tm_p_file?
> 
> *linux* targets that do not append to tm_p_file are 390x-*-linux* and
> s390x-ibm-tpf* and Andrew is already addressed this problem.

OK.

> 
> 
>> It seems that there are at least two separate problems:
>> 
>> 1. OPTION_BIONIC is not defined in linux-android.c .  I think the right fix here is to copy definitions of OPTION_BIONIC (and, optionally, OPTION_UCLIBC) from gcc/config/linux.h to rs6000/linux.h, rs6000/linux64.h and alpha/linux.h -- in other words, define OPTION_BIONIC and OPTION_UCLIBC whenever OPTION_GLIBC is defined.
> 
> Why can't we just use the checks like "if (linux_libc == LIBC_GLIBC)".
> Seems that we have all infrastructure in place (linux_libc,
> LIBC_GLIBC, LIBC_BIONIC, LIBC_UCLIBC are defined for all *linux*
> targets). I don't see the reason to make new defines.

Same reason why the existing defines are in place.  OPTION_X is not always the same as (linux_libc == LIBC_X).

> 
>> 2. The second problem is to do with definitions of TARGET_LIBC_HAS_FUNCTION for bfin, c6x, lm32, m68k and moxie.  What is the failure scenario here?
> 
> "For them we have ar: linux-android.o: No such file or directory" So I
> added t-linux-android rules to tmake_file.
> 
> (and for bfin additionally we have:
> "../../gcc/gcc/config/bfin/bfin.c:5812:29: error:
> ‘linux_android_libc_has_function’ was not declared in this scope".
> because
> the tm_p.h is not included in bfin.c)

OK.

> 
>> 
>>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>>> index 7e1d529..89cf30a 100644
>>> --- a/gcc/config.gcc
>>> +++ b/gcc/config.gcc
>>> @@ -1018,7 +1018,7 @@ bfin*-uclinux*)
>>> ;;
>>> bfin*-linux-uclibc*)
>>> tm_file="${tm_file} dbxelf.h elfos.h bfin/elf.h gnu-user.h linux.h
>>> glibc-stdint.h bfin/linux.h ./linux-sysroot-suffix.h"
>>> - tmake_file="bfin/t-bfin-linux t-slibgcc"
>>> + tmake_file="bfin/t-bfin-linux t-slibgcc t-linux-android"
>>> use_collect2=no
>>> ;;
>>> bfin*-rtems*)
>> 
>> Why?  Bfin has nothing to do with android.
> 
> Since ‘linux_android_libc_has_function’ handles all three libc options
> for all linux targets, that's natural to use this function. May be it
> should be called "linux_libc_has_function" and be located in linux.c
> (we don't have this file..).

OK.

Ideally we would have linux.c with linux_libc_has_function that knows nothing about Bionic and linux-android.c with linux_android_libc_has_function.

The patch is OK with definitions of OPTION_GLIBC, OPTION_UCLIBC and OPTION_BIONIC copied verbatim from gcc/config/linux.h to rs6000 and alpha versions.

It is then on my plate to refactor handling of Bionic libc and remove it from targets that don't support it.

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]