>>
>> confirming that this patch fixes the failing numpy regress test on i386.
>>
>> let me know if you want me to test a different diff.
>
> Here's a better diff, inspired by what FreeBSD has.
>
> ok?
>
>
ok with me. numpy works with this diff too.
On 6/4/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 21:18:26 -0400
>> From: Daniel Dickman
>>
>> >
>> > Another bug. Intel chose an extended precision format with an
>> > explicit integer bit, and the code doesn't handle that. Assuming we
>> > don't support machines with extended precision
> Date: Mon, 2 Jun 2014 21:18:26 -0400
> From: Daniel Dickman
>
> >
> > Another bug. Intel chose an extended precision format with an
> > explicit integer bit, and the code doesn't handle that. Assuming we
> > don't support machines with extended precision format that have an
> > implicit integ
>
> Another bug. Intel chose an extended precision format with an
> explicit integer bit, and the code doesn't handle that. Assuming we
> don't support machines with extended precision format that have an
> implicit integer bit, the following diff (an adaptation of the code in
> glibc) should fix
> Date: Mon, 2 Jun 2014 07:34:59 -0400
> From: Daniel Dickman
>
> >From the numpy test suite, I think I might have found a bug in
> nextafterl(3). The "result_ld" variable below comes back as nan on
> i386. But doing the same calculations with floats returns the expected
> values.
>
> A test on
>From the numpy test suite, I think I might have found a bug in
nextafterl(3). The "result_ld" variable below comes back as nan on
i386. But doing the same calculations with floats returns the expected
values.
A test on Linux also shows the expected results for both the float and
long double cases
