This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc-2.5 build with -Os broken on PowerPC
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: sparky at pld-linux dot org
- Cc: drepper at redhat dot com, libc-alpha at sourceware dot org
- Date: Fri, 3 Nov 2006 15:20:27 -0600
- Subject: Re: glibc-2.5 build with -Os broken on PowerPC
sparky@pld-linux.org wrote on 11/03/2006 11:35:29 AM:
> On Fri, Nov 03, 2006 at 09:03:31AM -0800, Ulrich Drepper wrote:
> > The correct solution is to not have the libc-internal block of code in
> > the header in the first place. Create a separate header and put it all
> > there.
>
> you mean # define __CPU_HAS_FSQRT something ?
>
> It isn't internal-only definition. It is used in inline __ieee754_sqrt
> function in bits/mathinline.h. That's why I don't know where to move
> those definitions.
>
You really must explain what you are doing and what does not work. Because
is works for me as of libc from 10/18.
For example what configure options are you using?
This is complicated by the fact the not all PowerPC32 hardware implements
fsqrt. So the current implement for powerpc32 uses a guard based on
checking for PPC_FEATURE_64 in the AT_HWCAP (#define __CPU_HAS_FSQRT
((GLRO(dl_hwcap) & PPC_FEATURE_64) != 0), fsqrt is implemented on all
64-bit processors).
So it is inappropriate to arbitrarily build fsqrt into libm for 32-bit
unless you have complete control over where the code will run (For example
powerpc_cpu add-on and --with-cpu=).
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center