Re: The state of glibc libm

On Wed, 29 Feb 2012, Joseph S. Myers wrote: > I've reviewed many (not yet all) of glibc's open "math" component bugs. I > hope some actual summary information on what the current state of libm > looks like may be of interest to the people involved in the various past > discussions of better li

Re: The state of glibc libm

On 2012-03-26 11:15:37 -0500, Steven Munroe wrote: > On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote: > > Then concerning double-double vs quad (binary128) for the "long double" > > type, I think that quad would be more useful, in particular because > > it has been standardized and it is a

Re: The state of glibc libm

On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote: > On 2012-03-22 16:29:00 +, Joseph S. Myers wrote: > > On Thu, 22 Mar 2012, Vincent Lefevre wrote: > > > For the same reason, if the user chose long double instead of > > > double, this may be because he wanted more precision than double

Re: The state of glibc libm

On 2012-03-22 16:29:00 +, Joseph S. Myers wrote: > On Thu, 22 Mar 2012, Vincent Lefevre wrote: > > For the same reason, if the user chose long double instead of > > double, this may be because he wanted more precision than double. > > You mean range? IBM long double provides more precision, b

Re: The state of glibc libm

On Thu, 22 Mar 2012, Vincent Lefevre wrote: > I initially thought that the only goal of a double-double format > (instead of the standard quadruple precision) was to get an > accurate implementation of the elementary functions in double > precision (BTW, that's probably why expl() and so on didn't

Re: The state of glibc libm

On 2012-03-15 10:52:05 -0500, Steven Munroe wrote: > On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote: > > On 2012-03-14 14:40:06 +, Joseph S. Myers wrote: > > > On Wed, 14 Mar 2012, Vincent Lefevre wrote: > > > > > > > For double-double (IBM long double), I don't think the notion of >

Re: The state of glibc libm

On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote: > On 2012-03-14 14:40:06 +, Joseph S. Myers wrote: > > On Wed, 14 Mar 2012, Vincent Lefevre wrote: > > > > > For double-double (IBM long double), I don't think the notion of > > > correct rounding makes much sense anyway. Actually the d

Re: The state of glibc libm

> "VL" == Vincent Lefevre writes: VL> sinf being slower than sin is surprising Some weeks back I wrote a simple app to output a couple of waveforms as float samples (I encased it in a tiny script which piped the output to sox to create a wav). I found that converting it to work on and outpu

Re: The state of glibc libm

Hello! >>> SSE ABI entries for i?86 in glibc were rejected. ?I proposed them like >>> 4-5 years ago to make -mfpmath=sse not suck. >> >> With the new libm hopefully this can be revisited. >> >> But there's the ABI and there's the internal implementation. >> >> My point was just that relying on x87

Re: The state of glibc libm

On Thu, Mar 15, 2012 at 3:17 PM, Andi Kleen wrote: >> SSE ABI entries for i?86 in glibc were rejected.  I proposed them like >> 4-5 years ago to make -mfpmath=sse not suck. > > With the new libm hopefully this can be revisited. > > But there's the ABI and there's the internal implementation. > > M

Re: The state of glibc libm

> SSE ABI entries for i?86 in glibc were rejected. I proposed them like > 4-5 years ago to make -mfpmath=sse not suck. With the new libm hopefully this can be revisited. But there's the ABI and there's the internal implementation. My point was just that relying on x87 fully again does not reall

Re: The state of glibc libm

On Wed, Mar 14, 2012 at 10:47 PM, Andi Kleen wrote: > On Wed, Mar 14, 2012 at 09:04:53PM +, Joseph S. Myers wrote: >> On Wed, 14 Mar 2012, Andi Kleen wrote: >> >> > One big win alone on 32bit x86 would be to use a SSE ABI for libm >> > by default. >> >> I haven't checked, but I'd hope x32 does

Re: The state of glibc libm

On 2012-03-14 14:40:06 +, Joseph S. Myers wrote: > On Wed, 14 Mar 2012, Vincent Lefevre wrote: > > > For double-double (IBM long double), I don't think the notion of > > correct rounding makes much sense anyway. Actually the double-double > > arithmetic is mainly useful for the basic operation

Re: The state of glibc libm

From: Jeff Law Date: Wed, 14 Mar 2012 10:41:27 -0600 > The better performance with potential loss of accuracy is an across > the board request, it's not just a sin/cos issue. All the trig, exp, > pow, log, etc, which I don't think are necessarily covered by using > the old x87 fp unit. This is

Re: The state of glibc libm

On Wed, Mar 14, 2012 at 09:04:53PM +, Joseph S. Myers wrote: > On Wed, 14 Mar 2012, Andi Kleen wrote: > > > One big win alone on 32bit x86 would be to use a SSE ABI for libm > > by default. > > I haven't checked, but I'd hope x32 does that as a better 32-bit ABI for > newer x86 processors.

Re: The state of glibc libm

On Wed, 14 Mar 2012, Marc Glisse wrote: > On Wed, 14 Mar 2012, Joseph S. Myers wrote: > > > I'd say that "better performance with the potential loss of accuracy" > > should be covered by -ffast-math - that GCC should generate direct use of > > fsin/fcos instructions for sin/cos for -O2 -funsafe-m

Re: The state of glibc libm

On Wed, 14 Mar 2012, Andi Kleen wrote: > One big win alone on 32bit x86 would be to use a SSE ABI for libm > by default. I haven't checked, but I'd hope x32 does that as a better 32-bit ABI for newer x86 processors. -- Joseph S. Myers jos...@codesourcery.com

Re: The state of glibc libm

On Wed, 14 Mar 2012, Joseph S. Myers wrote: I'd say that "better performance with the potential loss of accuracy" should be covered by -ffast-math - that GCC should generate direct use of fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on x86_64, as it does on x86, unless

Re: The state of glibc libm

Jeff Law writes: > On 03/14/2012 10:30 AM, Joseph S. Myers wrote: >> >> I'd say that "better performance with the potential loss of accuracy" >> should be covered by -ffast-math - that GCC should generate direct use of >> fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on >

Re: The state of glibc libm

On 03/14/2012 10:30 AM, Joseph S. Myers wrote: I'd say that "better performance with the potential loss of accuracy" should be covered by -ffast-math - that GCC should generate direct use of fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on x86_64, as it does on x86, unle

Re: The state of glibc libm

On Wed, 14 Mar 2012, Jeff Law wrote: > On 03/14/2012 08:30 AM, Vincent Lefevre wrote: > > > > > (b) Where functions do make attempts at being correctly rounded > > > (especially the IBM Accurate Mathematical Library functions), they tend to > > > be sufficiently slow that the slowness attracts bu

Re: The state of glibc libm

On 03/14/2012 08:30 AM, Vincent Lefevre wrote: (b) Where functions do make attempts at being correctly rounded (especially the IBM Accurate Mathematical Library functions), they tend to be sufficiently slow that the slowness attracts bug reports. Again, this would likely be addressed by new im

Re: The state of glibc libm

On Wed, 14 Mar 2012, Vincent Lefevre wrote: > For double-double (IBM long double), I don't think the notion of > correct rounding makes much sense anyway. Actually the double-double > arithmetic is mainly useful for the basic operations in order to be > able to implement elementary functions accur

Re: The state of glibc libm

On 2012-02-29 17:17:17 +, Joseph S. Myers wrote: > (a) Most libm functions are not correctly rounded - and do not make an > attempt at being correctly rounded. > > A full fix would likely require new (automatically generated and tuned) > implementations such as proposed at >

Re: The state of glibc libm

From: "Joseph S. Myers" Date: Wed, 29 Feb 2012 17:17:17 + (UTC) Thanks for looking into all of these issues. > (c) Various functions do not set errno correctly (many cases) or raise the > proper floating-point exceptions (a smaller number of cases - both > spurious exceptions where not per

The state of glibc libm

I've reviewed many (not yet all) of glibc's open "math" component bugs. I hope some actual summary information on what the current state of libm looks like may be of interest to the people involved in the various past discussions of better libm for GCC or glibc - and those interested in fixing