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

2013-09-05 Thread Kirill Yukhin 
Hello,
On 04 Sep 20:11, Maxim Kuvyrkov wrote:
 On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:
 The patch is OK with definitions of OPTION_GLIBC, OPTION_UCLIBC and 
 OPTION_BIONIC copied verbatim from gcc/config/l

Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00137.html

--
Thanks, K

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

2013-09-05 Thread Joseph S. Myers 
On Thu, 5 Sep 2013, Bernhard Reutner-Fischer wrote:

 uClibc has C99 math support optionally as well as other optional, nonstandard
 feature sets. Your patch does not seem to check (in a cross-compilable
 fashion, of course) if C99 math is supported in libc or not, thus regressing
 on uClibc with C99_MATH enabled.

It is a basic principle that it should be possible to bootstrap cross 
tools by building the compiler, once, then using it to build runtime 
libraries.  We haven't got there yet, but configure-time tests for library 
features that affect how the compiler behaves are best avoided so as to 
support such bootstraps - and if present, it's best for there to be a 
corresponding configure option to override them, and a command-line option 
to control things on a per-multilib basis.  To the extent that we do have 
configure support for checking library headers if those are available when 
the compiler is configured, it only supports checking the default multilib 
and not headers for other multilibs.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

2013-09-05 Thread Bernhard Reutner-Fischer 

On 5 September 2013 13:02:29 Kirill Yukhin kirill.yuk...@gmail.com wrote:

Hello,
On 04 Sep 20:11, Maxim Kuvyrkov wrote:
 On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:
 The patch is OK with definitions of OPTION_GLIBC, OPTION_UCLIBC and 
OPTION_BIONIC copied verbatim from gcc/config/l


Checked into main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00137.html



Unless i am missing something crucial I am not really convinced that this 
bionic support stuff you guys are aiming at is proper, to be defensive..


uClibc has C99 math support optionally as well as other optional, 
nonstandard feature sets. Your patch does not seem to check (in a 
cross-compilable fashion, of course) if C99 math is supported in libc or 
not, thus regressing on uClibc with C99_MATH enabled.


Please revert this patch and handle your libc in a sensible manner as 
everyone else has to since years.. I.e. either be C99 complete or fixup 
your conditions, ideally in the public port.


Thanks,


--
Thanks, K



Sent with AquaMail for Android
http://www.aqua-mail.com

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

2013-09-04 Thread Alexander Ivchenko 
Hi Maxim,

2013/9/4 Maxim Kuvyrkov ma...@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.


 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.

 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)


 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..).

 @@ -1053,7 +1053,7 @@ cris-*-elf | cris-*-none)
 crisv32-*-linux* | cris-*-linux*)
  tm_file=dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h
 glibc-stdint.h cris/linux.h
  # We need to avoid using t-linux, so override default tmake_file
 - tmake_file=cris/t-cris cris/t-linux t-slibgcc
 + tmake_file=cris/t-cris cris/t-linux t-slibgcc t-linux-android
  extra_options=${extra_options} cris/linux.opt
  case $target in
   cris-*-*)

 Same question here.

Please, see above.

 diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
 index 7fab975..18457f8 100644
 --- a/gcc/config/bfin/bfin.c
 +++ b/gcc/config/bfin/bfin.c
 @@ -46,6 +46,7 @@
 #include cgraph.h
 #include langhooks.h
 #include bfin-protos.h
 +#include tm_p.h
 #include tm-preds.h
 #include tm-constrs.h
 #include gt-bfin.h
 diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
 index ca0f4ee..63cba99 100644
 --- a/gcc/config/bfin/uclinux.h
 +++ b/gcc/config/bfin/uclinux.h
 @@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
 respectively.  If not, see
 #define TARGET_SUPPORTS_SYNC_CALLS 1

 #define SUBTARGET_FDPIC_NOT_SUPPORTED
 +
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
 index 5d61f4d..fa0937e 100644
 --- a/gcc/config/c6x/uclinux-elf.h
 +++ b/gcc/config/c6x/uclinux-elf.h
 @@ -62,3 +62,5 @@
 : 0 (_beg), b (_end), b (_scno)); \
 }

 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
 index 4a4b48d..e9d9e9a 100644
 --- a/gcc/config/linux-android.c
 +++ b/gcc/config/linux-android.c
 @@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
 bool
 linux_android_libc_has_function (enum function_class fn_class)
 {
 -  if (OPTION_GLIBC)
 +  if (linux_libc == LIBC_GLIBC)
 return true;
 -  if (OPTION_BIONIC)
 +  if (linux_libc == LIBC_BIONIC)
 if (fn_class == function_c94
  || fn_class == function_c99_misc
  || fn_class == function_sincos)

 The above hunk should not be necessary after (1).

 diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
 index 3a556d7..a5e8163 100644
 --- a/gcc/config/lm32/uclinux-elf.h
 +++ b/gcc/config/lm32/uclinux-elf.h
 @@ -77,3 +77,5 @@
 #undef  CC1_SPEC
 #define CC1_SPEC %{G*} %{!fno-PIC:-fPIC}

 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git

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

2013-09-04 Thread Maxim Kuvyrkov 
On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:

 Hi Maxim,
 
 2013/9/4 Maxim Kuvyrkov ma...@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

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

2013-09-03 Thread Michael Meissner 
On Thu, Aug 22, 2013 at 05:04:21PM +0400, 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*)
 
 (btw bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux* are
 broken now anyways:
 
 opening glibc-c.o: No such file or directory
 make[1]: *** [cc1-checksum.c] Error 1
 make[1]: *** Waiting for unfinished jobs...)
 
 Sorry again for the inconvenience, here is the updated patch that now,
 hopefully, fixes the issues with my initial patch.
 (Andreas patch still needs to be applied)
 
 Is it OK?
 
 diff --git a/gcc/ChangeLog b/gcc/ChangeLog
 index 6e27be2..2d15fb1 100644
 --- a/gcc/ChangeLog
 +++ b/gcc/ChangeLog
 @@ -1,3 +1,17 @@
 +2013-08-21  Alexander Ivchenko  alexander.ivche...@intel.com
 +
 + * config/linux-android.c (linux_android_libc_has_function): Fix
 + checks for libc.
 + * config/bfin/uclinux.h: Define TARGET_LIBC_HAS_FUNCTION as
 + no_c99_libc_has_function.
 + * config/c6x/uclinux-elf.h: Ditto.
 + * config/lm32/uclinux-elf.h: Ditto.
 + * config/m68k/uclinux.h: Ditto.
 + * config/moxie/uclinux.h: Ditto.
 + * config.gcc (bfin*-linux-uclibc*): Add t-linux-android to tmake_file.
 + (crisv32-*-linux*, cris-*-linux*): Ditto.
 + * config/bfin/bfin.c: Include tm_p.h.
 +
  2013-08-21  Joern Rennecke  joern.renne...@embecosm.com
 
   * reload.h (struct reg_equivs): Rename to ..

Please do not put diff's of the ChangeLog file in the patch.  Instead you
should have the ChangeLog parts in the message, and if it is more than a few
lines, the patch (without the ChangeLog bits) should be a separate attachment.
That allows us to apply the patch without an error.

I just got back from vacation, and noticed the powerpc linux compiler no longer
builds, and I've been reading my old mail from the last week or so.  I suspect
we will need similar patches for the powerpc.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

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

2013-09-03 Thread Maxim Kuvyrkov 
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?

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.

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?

 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.

 @@ -1053,7 +1053,7 @@ cris-*-elf | cris-*-none)
 crisv32-*-linux* | cris-*-linux*)
  tm_file=dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h
 glibc-stdint.h cris/linux.h
  # We need to avoid using t-linux, so override default tmake_file
 - tmake_file=cris/t-cris cris/t-linux t-slibgcc
 + tmake_file=cris/t-cris cris/t-linux t-slibgcc t-linux-android
  extra_options=${extra_options} cris/linux.opt
  case $target in
   cris-*-*)

Same question here.

 diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
 index 7fab975..18457f8 100644
 --- a/gcc/config/bfin/bfin.c
 +++ b/gcc/config/bfin/bfin.c
 @@ -46,6 +46,7 @@
 #include cgraph.h
 #include langhooks.h
 #include bfin-protos.h
 +#include tm_p.h
 #include tm-preds.h
 #include tm-constrs.h
 #include gt-bfin.h
 diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
 index ca0f4ee..63cba99 100644
 --- a/gcc/config/bfin/uclinux.h
 +++ b/gcc/config/bfin/uclinux.h
 @@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
 respectively.  If not, see
 #define TARGET_SUPPORTS_SYNC_CALLS 1
 
 #define SUBTARGET_FDPIC_NOT_SUPPORTED
 +
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
 index 5d61f4d..fa0937e 100644
 --- a/gcc/config/c6x/uclinux-elf.h
 +++ b/gcc/config/c6x/uclinux-elf.h
 @@ -62,3 +62,5 @@
 : 0 (_beg), b (_end), b (_scno)); \
 }
 
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
 index 4a4b48d..e9d9e9a 100644
 --- a/gcc/config/linux-android.c
 +++ b/gcc/config/linux-android.c
 @@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
 bool
 linux_android_libc_has_function (enum function_class fn_class)
 {
 -  if (OPTION_GLIBC)
 +  if (linux_libc == LIBC_GLIBC)
 return true;
 -  if (OPTION_BIONIC)
 +  if (linux_libc == LIBC_BIONIC)
 if (fn_class == function_c94
  || fn_class == function_c99_misc
  || fn_class == function_sincos)

The above hunk should not be necessary after (1).

 diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
 index 3a556d7..a5e8163 100644
 --- a/gcc/config/lm32/uclinux-elf.h
 +++ b/gcc/config/lm32/uclinux-elf.h
 @@ -77,3 +77,5 @@
 #undef  CC1_SPEC
 #define CC1_SPEC %{G*} %{!fno-PIC:-fPIC}
 
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/m68k/uclinux.h b/gcc/config/m68k/uclinux.h
 index 8d74312..b1af7d2 100644
 --- a/gcc/config/m68k/uclinux.h
 +++ b/gcc/config/m68k/uclinux.h
 @@ -67,3 +67,6 @@ along with GCC; see the file COPYING3.  If not see
sections.  */
 #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
 #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1
 +
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
 index 498037e..85c65f2 100644
 --- a/gcc/config/moxie/uclinux.h
 +++ b/gcc/config/moxie/uclinux.h
 @@ -37,3 +37,6 @@ see the files COPYING3 and COPYING.RUNTIME
 respectively.  If not, see
  --wrap=mmap --wrap=munmap --wrap=alloca\
  %{fmudflapth: --wrap=pthread_create\
 }} %{fmudflap|fmudflapth: --wrap=main}
 +
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
 
 

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com

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

2013-08-22 Thread Andreas Krebbel 
On Wed, Aug 21, 2013 at 11:21:32PM +0400, Alexander Ivchenko wrote:
 I'm sorry for that. The following patch cured my build of those
 targets; it is also preserving the initial presence of c99. There were
 plenty of targets that were changed by my patch, I hope this time I
 didn't miss anything.

S/390 bootstrap still fails. The reason is that when we set
tm_file/tm_p_file in config.gcc we do not append to the existing
content so your adjustments done before are ignored and gcc complains
about unknown linux_android_libc_has_function.

However, since with s390 Linux and TPF we only target GNU Linux
systems with Glibc we can default to gnu_libc_has_functions anyway:

Index: gcc/config/s390/linux.h
===
*** gcc/config/s390/linux.h.orig2013-01-14 07:48:06.0 +
--- gcc/config/s390/linux.h 2013-08-22 07:57:46.006014197 +
*** along with GCC; see the file COPYING3.
*** 87,90 
--- 87,93 
  /* Define if long doubles should be mangled as 'g'.  */
  #define TARGET_ALTERNATE_LONG_DOUBLE_MANGLING
  
+ #undef TARGET_LIBC_HAS_FUNCTION
+ #define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
+ 
  #endif
Index: gcc/config/s390/tpf.h
===
*** gcc/config/s390/tpf.h.orig  2013-08-22 07:01:48.0 +
--- gcc/config/s390/tpf.h   2013-08-22 07:57:27.706013534 +
*** along with GCC; see the file COPYING3.
*** 111,118 
  /* IBM copies these libraries over with these names.  */
  #define MATH_LIBRARY CLBM
  #define LIBSTDCXX CPP2
- #endif /* ! _TPF_H */
  
- /* We redefine this hook so the version from elfos.h header won't be used.  */
  #undef TARGET_LIBC_HAS_FUNCTION
! #define TARGET_LIBC_HAS_FUNCTION default_libc_has_function
--- 111,118 
  /* IBM copies these libraries over with these names.  */
  #define MATH_LIBRARY CLBM
  #define LIBSTDCXX CPP2
  
  #undef TARGET_LIBC_HAS_FUNCTION
! #define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
! 
! #endif /* ! _TPF_H */

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

2013-08-22 Thread Alexander Ivchenko 
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*)

(btw bfin*-linux-uclibc* or crisv32-*-linux* | cris-*-linux* are
broken now anyways:

opening glibc-c.o: No such file or directory
make[1]: *** [cc1-checksum.c] Error 1
make[1]: *** Waiting for unfinished jobs...)

Sorry again for the inconvenience, here is the updated patch that now,
hopefully, fixes the issues with my initial patch.
(Andreas patch still needs to be applied)

Is it OK?

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6e27be2..2d15fb1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17 @@
+2013-08-21  Alexander Ivchenko  alexander.ivche...@intel.com
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+ * config/bfin/uclinux.h: Define TARGET_LIBC_HAS_FUNCTION as
+ no_c99_libc_has_function.
+ * config/c6x/uclinux-elf.h: Ditto.
+ * config/lm32/uclinux-elf.h: Ditto.
+ * config/m68k/uclinux.h: Ditto.
+ * config/moxie/uclinux.h: Ditto.
+ * config.gcc (bfin*-linux-uclibc*): Add t-linux-android to tmake_file.
+ (crisv32-*-linux*, cris-*-linux*): Ditto.
+ * config/bfin/bfin.c: Include tm_p.h.
+
 2013-08-21  Joern Rennecke  joern.renne...@embecosm.com

  * reload.h (struct reg_equivs): Rename to ..
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*)
@@ -1053,7 +1053,7 @@ cris-*-elf | cris-*-none)
 crisv32-*-linux* | cris-*-linux*)
  tm_file=dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h
glibc-stdint.h cris/linux.h
  # We need to avoid using t-linux, so override default tmake_file
- tmake_file=cris/t-cris cris/t-linux t-slibgcc
+ tmake_file=cris/t-cris cris/t-linux t-slibgcc t-linux-android
  extra_options=${extra_options} cris/linux.opt
  case $target in
   cris-*-*)
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index 7fab975..18457f8 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -46,6 +46,7 @@
 #include cgraph.h
 #include langhooks.h
 #include bfin-protos.h
+#include tm_p.h
 #include tm-preds.h
 #include tm-constrs.h
 #include gt-bfin.h
diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
index ca0f4ee..63cba99 100644
--- a/gcc/config/bfin/uclinux.h
+++ b/gcc/config/bfin/uclinux.h
@@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
 #define TARGET_SUPPORTS_SYNC_CALLS 1

 #define SUBTARGET_FDPIC_NOT_SUPPORTED
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
index 5d61f4d..fa0937e 100644
--- a/gcc/config/c6x/uclinux-elf.h
+++ b/gcc/config/c6x/uclinux-elf.h
@@ -62,3 +62,5 @@
 : 0 (_beg), b (_end), b (_scno)); \
 }

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
index 4a4b48d..e9d9e9a 100644
--- a/gcc/config/linux-android.c
+++ b/gcc/config/linux-android.c
@@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
 bool
 linux_android_libc_has_function (enum function_class fn_class)
 {
-  if (OPTION_GLIBC)
+  if (linux_libc == LIBC_GLIBC)
 return true;
-  if (OPTION_BIONIC)
+  if (linux_libc == LIBC_BIONIC)
 if (fn_class == function_c94
  || fn_class == function_c99_misc
  || fn_class == function_sincos)
diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
index 3a556d7..a5e8163 100644
--- a/gcc/config/lm32/uclinux-elf.h
+++ b/gcc/config/lm32/uclinux-elf.h
@@ -77,3 +77,5 @@
 #undef  CC1_SPEC
 #define CC1_SPEC %{G*} %{!fno-PIC:-fPIC}

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/m68k/uclinux.h b/gcc/config/m68k/uclinux.h
index 8d74312..b1af7d2 100644
--- a/gcc/config/m68k/uclinux.h
+++ b/gcc/config/m68k/uclinux.h
@@ -67,3 +67,6 @@ along with GCC; see the file COPYING3.  If not see
sections.  */
 #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
 #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
index 498037e..85c65f2 100644
--- a/gcc/config/moxie/uclinux.h
+++ b/gcc/config/moxie/uclinux.h
@@ -37,3 +37,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
  --wrap=mmap --wrap=munmap --wrap=alloca\

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

2013-08-21 Thread Rainer Orth 
Alexander Ivchenko aivch...@gmail.com writes:

 Hi Joseph, thanks for your comments.

 I updated the patch:

 1) The function name as a second argument in libc_has_function target
 hook was removed - was not usefull so far.
 2) By using contrib/config-list.mk (thanks for the hint - great tool!)
 and analysing tm.h files and what is included in them I have checked
 197 targets. That analysis includes all issues that you raised in your
 comments - everything is fixed now. I don't like that sometimes we
 have to redefine the version of the hook back to the default one due
 to a poisoning of including elfos.h, but I couldn't find a better
 solution - I commented all those cases.

 Regtesting is in progress now. I have already tested the patch before,
 so I don't expect to see any new problems.

 If all the tests pass, is the patch OK for trunk?

Unfortunately, this patch broke Solaris 10+ bootstrap; it cannot have
been tested properly there:

In file included from ./tm.h:27:0,
 from /vol/gcc/src/hg/trunk/local/gcc/gencheck.c:23:
/vol/gcc/src/hg/trunk/local/gcc/config/sol2-10.h:21:4: error: /* within 
comment [-Werror=comment]
 /* /* Solaris 10 has the float and long double forms of math functions.
 ^
cc1plus: all warnings being treated as errors
make[3]: *** [build/gencheck.o] Error 1

Fixed as follows; bootstrapped without regressions on
i386-pc-solaris2.10, installed on mainline.

Rainer


2013-08-21  Rainer Orth  r...@cebitec.uni-bielefeld.de

* config/sol2-10.h (TARGET_LIBC_HAS_FUNCTION): Don't nest
comment.

diff --git a/gcc/config/sol2-10.h b/gcc/config/sol2-10.h
--- a/gcc/config/sol2-10.h
+++ b/gcc/config/sol2-10.h
@@ -18,7 +18,7 @@ You should have received a copy of the G
 along with GCC; see the file COPYING3.  If not see
 http://www.gnu.org/licenses/.  */
 
-/* /* Solaris 10 has the float and long double forms of math functions.
+/* Solaris 10 has the float and long double forms of math functions.
We redefine this hook so the version from elfos.h header won't be used.  */
 #undef TARGET_LIBC_HAS_FUNCTION
 #define TARGET_LIBC_HAS_FUNCTION default_libc_has_function

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

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

2013-08-21 Thread Alexander Ivchenko 
Hi, there are still a couple of problems with my patch:

The build is broken for the following targets:
1) *linux* targets that do not include config/linux.h in their tm.h
(e.g alpha-linux, ppc64-linux etc). For them we have:

../../../../gcc/gcc/config/linux-android.c: In function ‘bool
linux_android_libc_has_function(function_class)’:
../../../../gcc/gcc/config/linux-android.c:40:7: error:
‘OPTION_BIONIC’ was not declared in this scope
   if (OPTION_BIONIC)
   ^
make[2]: *** [linux-android.o] Error 1

This is adressed in the changes of config/linux-android.c: linux_libc,
LIBC_GLIBC and LIBC_BIONIC seem to be declared for all *linux*
targets.

2) *uclinux* targets that include config/linux.h. For *uclinux* we do
not use linux-protos.h, and therefore linux_android_libc_has_function
is not declared there.
I don't want to add aditional tmake_file, tm_p_file and extra_objs, so
I added explicit define of TARGET_LIBC_HAS_FUNCTION as
no_c99_libc_has_function for those targets.

I'm sorry for that. The following patch cured my build of those
targets; it is also preserving the initial presence of c99. There were
plenty of targets that were changed by my patch, I hope this time I
didn't miss anything.

Is it ok?

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6e27be2..02679f3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2013-08-21  Alexander Ivchenko  alexander.ivche...@intel.com
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+ * config/bfin/uclinux.h: Define TARGET_LIBC_HAS_FUNCTION as
+ no_c99_libc_has_function.
+ * config/c6x/uclinux-elf.h: Ditto.
+ * config/lm32/uclinux-elf.h: Ditto.
+ * config/m68k/uclinux.h: Ditto.
+ * config/moxie/uclinux.h: Ditto.
+
 2013-08-21  Joern Rennecke  joern.renne...@embecosm.com

  * reload.h (struct reg_equivs): Rename to ..
diff --git a/gcc/config/bfin/uclinux.h b/gcc/config/bfin/uclinux.h
index ca0f4ee..63cba99 100644
--- a/gcc/config/bfin/uclinux.h
+++ b/gcc/config/bfin/uclinux.h
@@ -44,3 +44,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
 #define TARGET_SUPPORTS_SYNC_CALLS 1

 #define SUBTARGET_FDPIC_NOT_SUPPORTED
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/c6x/uclinux-elf.h b/gcc/config/c6x/uclinux-elf.h
index 5d61f4d..fa0937e 100644
--- a/gcc/config/c6x/uclinux-elf.h
+++ b/gcc/config/c6x/uclinux-elf.h
@@ -62,3 +62,5 @@
 : 0 (_beg), b (_end), b (_scno)); \
 }

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
index 4a4b48d..e9d9e9a 100644
--- a/gcc/config/linux-android.c
+++ b/gcc/config/linux-android.c
@@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
 bool
 linux_android_libc_has_function (enum function_class fn_class)
 {
-  if (OPTION_GLIBC)
+  if (linux_libc == LIBC_GLIBC)
 return true;
-  if (OPTION_BIONIC)
+  if (linux_libc == LIBC_BIONIC)
 if (fn_class == function_c94
  || fn_class == function_c99_misc
  || fn_class == function_sincos)
diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
index 3a556d7..a5e8163 100644
--- a/gcc/config/lm32/uclinux-elf.h
+++ b/gcc/config/lm32/uclinux-elf.h
@@ -77,3 +77,5 @@
 #undef  CC1_SPEC
 #define CC1_SPEC %{G*} %{!fno-PIC:-fPIC}

+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/m68k/uclinux.h b/gcc/config/m68k/uclinux.h
index 8d74312..b1af7d2 100644
--- a/gcc/config/m68k/uclinux.h
+++ b/gcc/config/m68k/uclinux.h
@@ -67,3 +67,6 @@ along with GCC; see the file COPYING3.  If not see
sections.  */
 #undef M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
 #define M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P 1
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
index 498037e..85c65f2 100644
--- a/gcc/config/moxie/uclinux.h
+++ b/gcc/config/moxie/uclinux.h
@@ -37,3 +37,6 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
  --wrap=mmap --wrap=munmap --wrap=alloca\
  %{fmudflapth: --wrap=pthread_create\
 }} %{fmudflap|fmudflapth: --wrap=main}
+
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

thanks,
Alexander

2013/8/21 Rainer Orth r...@cebitec.uni-bielefeld.de:
 Alexander Ivchenko aivch...@gmail.com writes:

 Hi Joseph, thanks for your comments.

 I updated the patch:

 1) The function name as a second argument in libc_has_function target
 hook was removed - was not usefull so far.
 2) By using contrib/config-list.mk (thanks for the hint - great tool!)
 and analysing tm.h files and what is included in them I have checked
 197 targets. That analysis includes all issues that you raised in your
 comments - everything is fixed now. I don't like that sometimes we
 have to redefine the version of the hook

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

2013-08-19 Thread Kirill Yukhin 
 This is OK, with function_gnu removed (nothing appears to use it), if no 
 OS port maintainers object to the changes for their OSes within the next 
 week.
Hello,
Week is over.
Comitted to MT: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00447.html

--
Thanks, K

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

2013-08-09 Thread Joseph S. Myers 
On Sun, 28 Jul 2013, Alexander Ivchenko wrote:

 Hi Joseph, thanks for your comments.
 
 I updated the patch:
 
 1) The function name as a second argument in libc_has_function target
 hook was removed - was not usefull so far.
 2) By using contrib/config-list.mk (thanks for the hint - great tool!)
 and analysing tm.h files and what is included in them I have checked
 197 targets. That analysis includes all issues that you raised in your
 comments - everything is fixed now. I don't like that sometimes we
 have to redefine the version of the hook back to the default one due
 to a poisoning of including elfos.h, but I couldn't find a better
 solution - I commented all those cases.
 
 Regtesting is in progress now. I have already tested the patch before,
 so I don't expect to see any new problems.
 
 If all the tests pass, is the patch OK for trunk?

This is OK, with function_gnu removed (nothing appears to use it), if no 
OS port maintainers object to the changes for their OSes within the next 
week.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

2013-07-30 Thread Alexander Ivchenko 
Just to confirm that the patch successfully regtested on
x86_64-unknown-linux-gnu.


thanks,
Alexander

2013/7/29 Alexander Ivchenko aivch...@gmail.com:
 2013/7/28 Michael Eager ea...@eagerm.com:
 On 07/27/13 15:18, Alexander Ivchenko wrote:

 Hi Joseph, thanks for your comments.

 I updated the patch:



 2013/7/9 Joseph S. Myers jos...@codesourcery.com:



 * It looks rather like microblaze*-*-* don't use elfos.h, so meaning
 semantics aren't preserved for those (non-Linux) targets either.  Now, I
 don't know if there's a good reason for not using that file (ask the
 architecture maintainer), but in any case semantics should be preserved.



 I don't know why microblaze does not include elfos.h.   It looks like
 it should, to be consistent with other targets.  This would require some
 cleanup and verification.

 Your patch adds the following to microblaze.h, duplicating the change
 to elfos.h:
 +/* microblaze-unknown-elf target has no support of C99 runtime */
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

 I'm assuming that this means that no other change to microblaze is
 needed and the question about elfos.h is moot.

 Yes, with this change in my patch the semantics for
 microblaze-unknown-elf is preserved. As for
 microblaze-unknown-linux-gnu case - the
 linux_android_libc_has_function version of TARGET_LIBC_HAS_FUNCTION
 from linux.h will be used, so the semantics is preserved as well.

 --Alexander

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

2013-07-28 Thread Michael Eager 

On 07/27/13 15:18, Alexander Ivchenko wrote:

Hi Joseph, thanks for your comments.

I updated the patch:




2013/7/9 Joseph S. Myers jos...@codesourcery.com:




* It looks rather like microblaze*-*-* don't use elfos.h, so meaning
semantics aren't preserved for those (non-Linux) targets either.  Now, I
don't know if there's a good reason for not using that file (ask the
architecture maintainer), but in any case semantics should be preserved.



I don't know why microblaze does not include elfos.h.   It looks like
it should, to be consistent with other targets.  This would require some
cleanup and verification.

Your patch adds the following to microblaze.h, duplicating the change
to elfos.h:
+/* microblaze-unknown-elf target has no support of C99 runtime */
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

I'm assuming that this means that no other change to microblaze is
needed and the question about elfos.h is moot.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

2013-07-28 Thread Alexander Ivchenko 
2013/7/28 Michael Eager ea...@eagerm.com:
 On 07/27/13 15:18, Alexander Ivchenko wrote:

 Hi Joseph, thanks for your comments.

 I updated the patch:



 2013/7/9 Joseph S. Myers jos...@codesourcery.com:



 * It looks rather like microblaze*-*-* don't use elfos.h, so meaning
 semantics aren't preserved for those (non-Linux) targets either.  Now, I
 don't know if there's a good reason for not using that file (ask the
 architecture maintainer), but in any case semantics should be preserved.



 I don't know why microblaze does not include elfos.h.   It looks like
 it should, to be consistent with other targets.  This would require some
 cleanup and verification.

 Your patch adds the following to microblaze.h, duplicating the change
 to elfos.h:
 +/* microblaze-unknown-elf target has no support of C99 runtime */
 +#undef TARGET_LIBC_HAS_FUNCTION
 +#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

 I'm assuming that this means that no other change to microblaze is
 needed and the question about elfos.h is moot.

Yes, with this change in my patch the semantics for
microblaze-unknown-elf is preserved. As for
microblaze-unknown-linux-gnu case - the
linux_android_libc_has_function version of TARGET_LIBC_HAS_FUNCTION
from linux.h will be used, so the semantics is preserved as well.

--Alexander

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

2013-07-08 Thread Joseph S. Myers 
On Thu, 28 Mar 2013, Alexander Ivchenko wrote:

 Hi,
 
 4.8 is now branched, lets come back to the discussion that we had
 before. I updated the patch a little
 bit since we now have linux-protos.h and linux-android.c files.
 
 I tried to preserve the avaiability of c99 for all targets, but it's
 pretty difficult, because we are changing
 the defaults. Passing an empty string as second argument doesn't look
 very good, but on the other hand
 the user has one clear way for checking the presence of a certain
 function. But of course we can create
 another function, that will call targetm.libc_has_function
 (function_class, ) within itself.

Observations on this patch version:

* You still shouldn't be calling with  as function name (or 0, in 
i386.md) unless there's a good reason the relevant function can't readily 
be identified.  (Actually, the TARGET_C99_FUNCTIONS checks in i386.md seem 
wrong - the instruction patterns expand things inline and the semantics of 
an isinf insn pattern are nothing to do with whether the target library 
has C99 functions; C99 doesn't provide isinf as a function anyway, only as 
a macro.)  If you don't yet need the name in any hook implementation, feel 
free to define the hooks without the name argument and it can be added 
later if needed.

* I don't see how your change for Darwin preserves the existing semantics; 
you appear to make it use no_c99_libc_has_function, but the existing 
semantics are that it has C99 functions except for 32-bit powerpc Darwin 
versions older than 10.3.

* I don't see how your change preserves semantics for Solaris either - you 
add a definition in sol2.h (for Solaris 9) but don't override it in 
sol2-10.h (for Solaris 10, which has the C99 functions).

* I don't see anything to preserve semantics for AIX 4.3 and 5.1 (the AIX 
versions for which TARGET_C99_FUNCTIONS was not defined).

* I don't see anything to preserve semantics for alpha*-dec-*vms*.

* I don't see anything to preserve semantics for hppa*-*-hpux*.

* I don't see anything to preserve semantics for 
i[34567]86-pc-msdosdjgpp*.

* I don't see anything to preserve semantics for i[34567]86-*-cygwin*, or 
x86_64-*-cygwin*, or i[34567]86-*-mingw*, or x86_64-*-mingw*, or 
i[34567]86-*-interix[3-9]*.

* It looks rather like microblaze*-*-* don't use elfos.h, so meaning 
semantics aren't preserved for those (non-Linux) targets either.  Now, I 
don't know if there's a good reason for not using that file (ask the 
architecture maintainer), but in any case semantics should be preserved.

* I don't see anything to preserve semantics for mmix-knuth-mmixware, or 
pdp11-*-*, or picochip-* (more non-ELF targets).

* The patch is missing the poisoning of the removed target macros in 
system.h.

Now, for verifying semantics are unchanged for existing targets, you might 
want to adapt contrib/config-list.mk to show in some way the 
TARGET_C99_FUNCTIONS setting resulting from tm.h (before your patch) or 
the new hook setting (after your patch), so you can compare for all the 
targets listed there.  That's not perfect - the list of targets may not be 
complete - but if you fix all the issues listed above then 
before-and-after comparison for lots of targets using config-list.mk would 
be a good way of gaining confidence in the lack of unintended changes in 
the patch.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

2013-06-19 Thread Alexander Ivchenko 
 I don't see how a target hook is required for the command-line idea.
 Targets already have a perfectly working way of changing the default
 of a command-line option.

That's true.. sorry, my bad.

Anyway, could somebody take a look at the patch itself?

--Alexander



 2013/4/23 Alexander Ivchenko aivch...@gmail.com:
 *ping*

 thanks
 Alexander

 2013/3/28 Alexander Ivchenko aivch...@gmail.com:
 Hi,

 4.8 is now branched, lets come back to the discussion that we had
 before. I updated the patch a little
 bit since we now have linux-protos.h and linux-android.c files.

 I tried to preserve the avaiability of c99 for all targets, but it's
 pretty difficult, because we are changing
 the defaults. Passing an empty string as second argument doesn't look
 very good, but on the other hand
 the user has one clear way for checking the presence of a certain
 function. But of course we can create
 another function, that will call targetm.libc_has_function
 (function_class, ) within itself.

 best regards,
 Alexander

 2013/1/7 Joseph S. Myers jos...@codesourcery.com:
 On Fri, 21 Dec 2012, Alexander Ivchenko wrote:

 Hi,

 Thank you very much for your input! Please, take a look at the updated 
 version:
 I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
 to target.def.
 Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
 influence and moved the implementation of linux_libc_has_function to
 host-linux.c.
   I changed the defaults: now it is assumed that we have C99 runtime,
 but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in
 this part,
 cause I don't have the opportunity to test it properly...

 This patch seems mostly plausible, though there are various places that
 call targetm.libc_has_function with and empty string as second argument,
 that should be naming the specific function instead.  I haven't reviewed
 the details, and at this development stage I think it will need to wait
 until after 4.8 branches.

 --
 Joseph S. Myers
 jos...@codesourcery.com

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

2013-06-13 Thread Richard Biener 
On Mon, May 27, 2013 at 11:15 AM, Alexander Ivchenko aivch...@gmail.com wrote:
 Hi,

 While discussing the issue with the command line option for sincos here:
 http://gcc.1065356.n5.nabble.com/PATCH-bionic-Add-foptimize-sincos-tp940918.html

 Richard wrote:
 I'd rather think about a way to specify, for all known builtins, whether GCC
 should generate calls to such function where they are not in the source
 program.  That is, similar to how we have -f[no-]builtin-FOO introduce
 -f[no-]libc-FOO (with a better name for 'libc'?).  That way there would be
 a way to specify that -floop-distribute-patterns should not produce calls
 to memset () for example.

 This patch is related to that idea: in the target hook
 libc_has_function we can check whether
 the compiler should generate calls to a particular function or not.
 The command line support for
 each function could be the next step.

 Could you please take a look?

I don't see how a target hook is required for the command-line idea.
Targets already have a perfectly working way of changing the default
of a command-line option.

Richard.

 thanks
 Alexander

 2013/4/23 Alexander Ivchenko aivch...@gmail.com:
 *ping*

 thanks
 Alexander

 2013/3/28 Alexander Ivchenko aivch...@gmail.com:
 Hi,

 4.8 is now branched, lets come back to the discussion that we had
 before. I updated the patch a little
 bit since we now have linux-protos.h and linux-android.c files.

 I tried to preserve the avaiability of c99 for all targets, but it's
 pretty difficult, because we are changing
 the defaults. Passing an empty string as second argument doesn't look
 very good, but on the other hand
 the user has one clear way for checking the presence of a certain
 function. But of course we can create
 another function, that will call targetm.libc_has_function
 (function_class, ) within itself.

 best regards,
 Alexander

 2013/1/7 Joseph S. Myers jos...@codesourcery.com:
 On Fri, 21 Dec 2012, Alexander Ivchenko wrote:

 Hi,

 Thank you very much for your input! Please, take a look at the updated 
 version:
 I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
 to target.def.
 Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
 influence and moved the implementation of linux_libc_has_function to
 host-linux.c.
   I changed the defaults: now it is assumed that we have C99 runtime,
 but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in
 this part,
 cause I don't have the opportunity to test it properly...

 This patch seems mostly plausible, though there are various places that
 call targetm.libc_has_function with and empty string as second argument,
 that should be naming the specific function instead.  I haven't reviewed
 the details, and at this development stage I think it will need to wait
 until after 4.8 branches.

 --
 Joseph S. Myers
 jos...@codesourcery.com

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

2013-05-27 Thread Alexander Ivchenko 
Hi,

While discussing the issue with the command line option for sincos here:
http://gcc.1065356.n5.nabble.com/PATCH-bionic-Add-foptimize-sincos-tp940918.html

Richard wrote:
 I'd rather think about a way to specify, for all known builtins, whether GCC
 should generate calls to such function where they are not in the source
 program.  That is, similar to how we have -f[no-]builtin-FOO introduce
 -f[no-]libc-FOO (with a better name for 'libc'?).  That way there would be
 a way to specify that -floop-distribute-patterns should not produce calls
 to memset () for example.

This patch is related to that idea: in the target hook
libc_has_function we can check whether
the compiler should generate calls to a particular function or not.
The command line support for
each function could be the next step.

Could you please take a look?

thanks
Alexander

2013/4/23 Alexander Ivchenko aivch...@gmail.com:
 *ping*

 thanks
 Alexander

 2013/3/28 Alexander Ivchenko aivch...@gmail.com:
 Hi,

 4.8 is now branched, lets come back to the discussion that we had
 before. I updated the patch a little
 bit since we now have linux-protos.h and linux-android.c files.

 I tried to preserve the avaiability of c99 for all targets, but it's
 pretty difficult, because we are changing
 the defaults. Passing an empty string as second argument doesn't look
 very good, but on the other hand
 the user has one clear way for checking the presence of a certain
 function. But of course we can create
 another function, that will call targetm.libc_has_function
 (function_class, ) within itself.

 best regards,
 Alexander

 2013/1/7 Joseph S. Myers jos...@codesourcery.com:
 On Fri, 21 Dec 2012, Alexander Ivchenko wrote:

 Hi,

 Thank you very much for your input! Please, take a look at the updated 
 version:
 I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
 to target.def.
 Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
 influence and moved the implementation of linux_libc_has_function to
 host-linux.c.
   I changed the defaults: now it is assumed that we have C99 runtime,
 but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in
 this part,
 cause I don't have the opportunity to test it properly...

 This patch seems mostly plausible, though there are various places that
 call targetm.libc_has_function with and empty string as second argument,
 that should be naming the specific function instead.  I haven't reviewed
 the details, and at this development stage I think it will need to wait
 until after 4.8 branches.

 --
 Joseph S. Myers
 jos...@codesourcery.com

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

2013-04-23 Thread Alexander Ivchenko 
*ping*

thanks
Alexander

2013/3/28 Alexander Ivchenko aivch...@gmail.com:
 Hi,

 4.8 is now branched, lets come back to the discussion that we had
 before. I updated the patch a little
 bit since we now have linux-protos.h and linux-android.c files.

 I tried to preserve the avaiability of c99 for all targets, but it's
 pretty difficult, because we are changing
 the defaults. Passing an empty string as second argument doesn't look
 very good, but on the other hand
 the user has one clear way for checking the presence of a certain
 function. But of course we can create
 another function, that will call targetm.libc_has_function
 (function_class, ) within itself.

 best regards,
 Alexander

 2013/1/7 Joseph S. Myers jos...@codesourcery.com:
 On Fri, 21 Dec 2012, Alexander Ivchenko wrote:

 Hi,

 Thank you very much for your input! Please, take a look at the updated 
 version:
 I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
 to target.def.
 Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
 influence and moved the implementation of linux_libc_has_function to
 host-linux.c.
   I changed the defaults: now it is assumed that we have C99 runtime,
 but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in
 this part,
 cause I don't have the opportunity to test it properly...

 This patch seems mostly plausible, though there are various places that
 call targetm.libc_has_function with and empty string as second argument,
 that should be naming the specific function instead.  I haven't reviewed
 the details, and at this development stage I think it will need to wait
 until after 4.8 branches.

 --
 Joseph S. Myers
 jos...@codesourcery.com

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

2013-01-07 Thread Joseph S. Myers 
On Fri, 21 Dec 2012, Alexander Ivchenko wrote:

 Hi,
 
 Thank you very much for your input! Please, take a look at the updated 
 version:
 I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
 to target.def.
 Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
 influence and moved the implementation of linux_libc_has_function to
 host-linux.c.
   I changed the defaults: now it is assumed that we have C99 runtime,
 but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in
 this part,
 cause I don't have the opportunity to test it properly...

This patch seems mostly plausible, though there are various places that 
call targetm.libc_has_function with and empty string as second argument, 
that should be naming the specific function instead.  I haven't reviewed 
the details, and at this development stage I think it will need to wait 
until after 4.8 branches.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

2012-12-19 Thread Joseph S. Myers 
On Thu, 13 Dec 2012, Alexander Ivchenko wrote:

 Could you please take a look at the attached patch that implements
 the target libc_has_function hook? I didn't change so far the default presence
 of c99, but rather tried to preserve the current behaviour of
 TARGET_C99_FUNCTIONS.

It looks like a plausible starting point, given the changed default, 
coding style fixes (you're missing spaces before '('), documentation text 
moved from tm.texi.in to target.def, removal of TARGET_C99_FUNCTIONS 
documentation, poisoning of TARGET_C99_FUNCTIONS in system.h and moving 
the Linux implementation of the hook from builtins.c to some 
Linux-specific file since you can't assume OPTION_GLIBC or OPTION_BIONIC 
are defined for other targets.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

2012-12-13 Thread Alexander Ivchenko 
Hello!

Could you please take a look at the attached patch that implements
the target libc_has_function hook? I didn't change so far the default presence
of c99, but rather tried to preserve the current behaviour of
TARGET_C99_FUNCTIONS.

Thank you,
Alexander

2012/12/1 Joseph S. Myers jos...@codesourcery.com:
 On Fri, 30 Nov 2012, Richard Biener wrote:

 If you want to split TARGET_C99_FUNCTIONS then split it properly,
 don't add TARGET_HAS_BIONIC to the selection.

 Joseph may provide some guidance here.

 My suggested interface would be a target hook such as
 targetm.libc_has_function, taking two arguments, one of which is an enum
 value describing the general class of function (e.g.
 function_c99_misc, function_c99_math_complex, function_gnu) and the other
 of which is a string with the exact function name.  This could replace
 both the target macros TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS.

 I think the default version of the hook should be that all C99 functions
 are present, but not sincos, though that requires some care in the
 conversion to keep the settings for all systems the same, since the
 present default for TARGET_C99_FUNCTIONS is 0.  There would then be an
 always-true version of the hook for non-Linux glibc systems, and one that
 checks which C library is in use for Linux systems that might or might not
 be using glibc; this last one is where the Bionic check would go.

 (Given this is mainly about the target OS rather than the target CPU
 architecture, I guess the macro choosing a hook implementation would get
 defined in .h files rather than directly in arch.c.)

 --
 Joseph S. Myers
 jos...@codesourcery.com


libc_has_function.patch
Description: Binary data

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

2012-11-30 Thread Richard Biener 
On Fri, Nov 30, 2012 at 2:17 PM, Alexander Ivchenko aivch...@gmail.com wrote:
 Bionic has the support of almost all built-in functions from C99 iso
 standard except for only complex math functions.
 (I assume because bionic wants to be as small as possible and nobody
 wants to do complex arithmetic on Android).
 GCC however checks whether the runtime has the full support of C99 or
 not, and if not it completely turns off all C99 builtins.

 It seems that we are missing the optimization opportunity here and
 this patch (attached) is intended to turn on built-ins that are
 supported
 in bionic.

If you want to split TARGET_C99_FUNCTIONS then split it properly,
don't add TARGET_HAS_BIONIC to the selection.

Joseph may provide some guidance here.

Richard.

 bootstrap/tests are ok.

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

2012-11-30 Thread Joseph S. Myers 
On Fri, 30 Nov 2012, Richard Biener wrote:

 If you want to split TARGET_C99_FUNCTIONS then split it properly,
 don't add TARGET_HAS_BIONIC to the selection.
 
 Joseph may provide some guidance here.

My suggested interface would be a target hook such as 
targetm.libc_has_function, taking two arguments, one of which is an enum 
value describing the general class of function (e.g. 
function_c99_misc, function_c99_math_complex, function_gnu) and the other 
of which is a string with the exact function name.  This could replace 
both the target macros TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS.

I think the default version of the hook should be that all C99 functions 
are present, but not sincos, though that requires some care in the 
conversion to keep the settings for all systems the same, since the 
present default for TARGET_C99_FUNCTIONS is 0.  There would then be an 
always-true version of the hook for non-Linux glibc systems, and one that 
checks which C library is in use for Linux systems that might or might not 
be using glibc; this last one is where the Bionic check would go.

(Given this is mainly about the target OS rather than the target CPU 
architecture, I guess the macro choosing a hook implementation would get 
defined in .h files rather than directly in arch.c.)

-- 
Joseph S. Myers
jos...@codesourcery.com