Re: BUG in libm's powf
> On 6 Sep 2021, at 21:22, Gordon Bergling wrote:
>
> could you turn to test program into an AFT test to prevent further
> regressions?
Certainly!
M
>
> —Gordon
>
>> Am 06.09.2021 um 20:04 schrieb Steve Kargl
>> :
>>
>> No, thank you for the quick response.
>>
>> Of course, a one character diff might be easier to review. :-)
>>
>> --
>> steve
>>
>> On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
>>> Thanks!
>>>
>>> And it's committed!
>>>
>>> M
>>>
On 6 Sep 2021, at 18:53, Steve Kargl
wrote:
Fine with me. I don't have a phabricator account and
bugzilla reports seems to get lost in the ether.
--
steve
On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> Hi
>
> I've opened a Phab ticket for this. I hope that's OK?
>
> https://reviews.freebsd.org/D31865
>
> M
>
>> On 6 Sep 2021, at 16:28, Steve Kargl
>> wrote:
>>
>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>> which is identical to FreeBSD's libm. Both derived from
>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>
>> Consider
>>
>> % cat h.c
>> #include
>> #include
>> int
>> main(void)
>> {
>> float x, y, z;
>> x = 0x1.ecp-1F;
>> y = -0x1.02p+27F;
>> z = 0x1.557a86p115F;
>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>> return 0;
>> }
>>
>> % cc -o h -fno-builtin h.c -lm && ./h
>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>
>> Note, clang seems to have a builtin for powf(), but one cannot
>> count of clang being the only consumer of libm. With the patch
>> at the end of this email, I get
>>
>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath &&
>> ./h
>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>
>> Watch for copy and paste whitespace corruption.
>>
>> --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000
>> -0800
>> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
>> @@ -136,7 +136,7 @@
>> /* |y| is huge */
>> if(iy>0x4d00) { /* if |y| > 2**27 */
>> /* over/underflow if x is not close to one */
>> -if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>> +if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>> log(x) by x-x^2/2+x^3/3-x^4/4 */
>>
>>
>> --
>> Steve
>>
>
> --
> Mark R V Murray
>
--
Steve
>>>
>>> --
>>> Mark R V Murray
>>>
>>
>>
>>
>> --
>> Steve
>>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: BUG in libm's powf
Hi! > > > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > > > could you turn to test program into an AFT test to prevent further > > > > regressions? > > > > > > I cannot tell if you are addressing Mark or me. > > > For me, I know nothing about ATF. > > > > man 7 atf > > > > has more details. > % man 7 atf > No manual entry for atf > % grep -i tests /etc/src.conf > WITHOUT_GOOGLETEST="YES" > WITHOUT_TESTS="YES" https://www.freebsd.org/cgi/man.cgi?query=atf -- p...@opsec.eu+49 171 3101372Now what ?
Re: BUG in libm's powf
On Mon, Sep 06, 2021 at 10:40:21PM +0200, Kurt Jaeger wrote: > Hi! > > > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > > could you turn to test program into an AFT test to prevent further > > > regressions? > > > > I cannot tell if you are addressing Mark or me. > > For me, I know nothing about ATF. > > man 7 atf > > has more details. > % man 7 atf No manual entry for atf % grep -i tests /etc/src.conf WITHOUT_GOOGLETEST="YES" WITHOUT_TESTS="YES" -- Steve
Re: BUG in libm's powf
Hi! > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > > could you turn to test program into an AFT test to prevent further > > regressions? > > I cannot tell if you are addressing Mark or me. > For me, I know nothing about ATF. man 7 atf has more details. -- p...@opsec.eu+49 171 3101372Now what ?
Re: BUG in libm's powf
On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote: > could you turn to test program into an AFT test to prevent further > regressions? > > —Gordon > I cannot tell if you are addressing Mark or me. For me, I know nothing about ATF. I do, however, suspect that this won't regress as I'm one of the few people who actually looks at threshold issues in libm. -- Steve
Re: BUG in libm's powf
No, thank you for the quick response.
Of course, a one character diff might be easier to review. :-)
--
steve
On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
> Thanks!
>
> And it's committed!
>
> M
>
> > On 6 Sep 2021, at 18:53, Steve Kargl
> > wrote:
> >
> > Fine with me. I don't have a phabricator account and
> > bugzilla reports seems to get lost in the ether.
> >
> > --
> > steve
> >
> > On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> >> Hi
> >>
> >> I've opened a Phab ticket for this. I hope that's OK?
> >>
> >> https://reviews.freebsd.org/D31865
> >>
> >> M
> >>
> >>> On 6 Sep 2021, at 16:28, Steve Kargl
> >>> wrote:
> >>>
> >>> Paul Zimmermann has identified a bug in Openlibm's powf(),
> >>> which is identical to FreeBSD's libm. Both derived from
> >>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> >>>
> >>> Consider
> >>>
> >>> % cat h.c
> >>> #include
> >>> #include
> >>> int
> >>> main(void)
> >>> {
> >>> float x, y, z;
> >>> x = 0x1.ecp-1F;
> >>> y = -0x1.02p+27F;
> >>> z = 0x1.557a86p115F;
> >>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> >>> return 0;
> >>> }
> >>>
> >>> % cc -o h -fno-builtin h.c -lm && ./h
> >>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> >>>
> >>> Note, clang seems to have a builtin for powf(), but one cannot
> >>> count of clang being the only consumer of libm. With the patch
> >>> at the end of this email, I get
> >>>
> >>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath &&
> >>> ./h
> >>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> >>>
> >>> Watch for copy and paste whitespace corruption.
> >>>
> >>> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000
> >>> -0800
> >>> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
> >>> @@ -136,7 +136,7 @@
> >>>/* |y| is huge */
> >>> if(iy>0x4d00) { /* if |y| > 2**27 */
> >>> /* over/underflow if x is not close to one */
> >>> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> >>> /* now |1-x| is tiny <= 2**-20, suffice to compute
> >>> log(x) by x-x^2/2+x^3/3-x^4/4 */
> >>>
> >>>
> >>> --
> >>> Steve
> >>>
> >>
> >> --
> >> Mark R V Murray
> >>
> >
> >
> >
> > --
> > Steve
> >
>
> --
> Mark R V Murray
>
--
Steve
Re: BUG in libm's powf
Thanks!
And it's committed!
M
> On 6 Sep 2021, at 18:53, Steve Kargl
> wrote:
>
> Fine with me. I don't have a phabricator account and
> bugzilla reports seems to get lost in the ether.
>
> --
> steve
>
> On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
>> Hi
>>
>> I've opened a Phab ticket for this. I hope that's OK?
>>
>> https://reviews.freebsd.org/D31865
>>
>> M
>>
>>> On 6 Sep 2021, at 16:28, Steve Kargl
>>> wrote:
>>>
>>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>>> which is identical to FreeBSD's libm. Both derived from
>>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>>
>>> Consider
>>>
>>> % cat h.c
>>> #include
>>> #include
>>> int
>>> main(void)
>>> {
>>> float x, y, z;
>>> x = 0x1.ecp-1F;
>>> y = -0x1.02p+27F;
>>> z = 0x1.557a86p115F;
>>> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>>> return 0;
>>> }
>>>
>>> % cc -o h -fno-builtin h.c -lm && ./h
>>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>>
>>> Note, clang seems to have a builtin for powf(), but one cannot
>>> count of clang being the only consumer of libm. With the patch
>>> at the end of this email, I get
>>>
>>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
>>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>>
>>> Watch for copy and paste whitespace corruption.
>>>
>>> --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000 -0800
>>> +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
>>> @@ -136,7 +136,7 @@
>>>/* |y| is huge */
>>> if(iy>0x4d00) { /* if |y| > 2**27 */
>>> /* over/underflow if x is not close to one */
>>> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>>>log(x) by x-x^2/2+x^3/3-x^4/4 */
>>>
>>>
>>> --
>>> Steve
>>>
>>
>> --
>> Mark R V Murray
>>
>
>
>
> --
> Steve
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: BUG in libm's powf
Fine with me. I don't have a phabricator account and
bugzilla reports seems to get lost in the ether.
--
steve
On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> Hi
>
> I've opened a Phab ticket for this. I hope that's OK?
>
> https://reviews.freebsd.org/D31865
>
> M
>
> > On 6 Sep 2021, at 16:28, Steve Kargl
> > wrote:
> >
> > Paul Zimmermann has identified a bug in Openlibm's powf(),
> > which is identical to FreeBSD's libm. Both derived from
> > fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> >
> > Consider
> >
> > % cat h.c
> > #include
> > #include
> > int
> > main(void)
> > {
> > float x, y, z;
> > x = 0x1.ecp-1F;
> > y = -0x1.02p+27F;
> > z = 0x1.557a86p115F;
> > printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> > return 0;
> > }
> >
> > % cc -o h -fno-builtin h.c -lm && ./h
> > 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> >
> > Note, clang seems to have a builtin for powf(), but one cannot
> > count of clang being the only consumer of libm. With the patch
> > at the end of this email, I get
> >
> > % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> > 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> >
> > Watch for copy and paste whitespace corruption.
> >
> > --- /usr/src/lib/msun/src/e_powf.c 2021-02-21 03:29:00.956878000 -0800
> > +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
> > @@ -136,7 +136,7 @@
> > /* |y| is huge */
> > if(iy>0x4d00) { /* if |y| > 2**27 */
> > /* over/underflow if x is not close to one */
> > - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> > /* now |1-x| is tiny <= 2**-20, suffice to compute
> >log(x) by x-x^2/2+x^3/3-x^4/4 */
> >
> >
> > --
> > Steve
> >
>
> --
> Mark R V Murray
>
--
Steve
Re: BUG in libm's powf
Hi
I've opened a Phab ticket for this. I hope that's OK?
https://reviews.freebsd.org/D31865
M
> On 6 Sep 2021, at 16:28, Steve Kargl
> wrote:
>
> Paul Zimmermann has identified a bug in Openlibm's powf(),
> which is identical to FreeBSD's libm. Both derived from
> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>
> Consider
>
> % cat h.c
> #include
> #include
> int
> main(void)
> {
> float x, y, z;
> x = 0x1.ecp-1F;
> y = -0x1.02p+27F;
> z = 0x1.557a86p115F;
> printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> return 0;
> }
>
> % cc -o h -fno-builtin h.c -lm && ./h
> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>
> Note, clang seems to have a builtin for powf(), but one cannot
> count of clang being the only consumer of libm. With the patch
> at the end of this email, I get
>
> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>
> Watch for copy and paste whitespace corruption.
>
> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000 -0800
> +++ src/e_powf.c 2021-09-06 08:17:09.88000 -0700
> @@ -136,7 +136,7 @@
> /* |y| is huge */
> if(iy>0x4d00) { /* if |y| > 2**27 */
> /* over/underflow if x is not close to one */
> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> /* now |1-x| is tiny <= 2**-20, suffice to compute
> log(x) by x-x^2/2+x^3/3-x^4/4 */
>
>
> --
> Steve
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
