Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jan 2015 13:53:52 -0800
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, Garrett Cooper <ngie@freebsd.org>
Subject:   Re: svn commit: r276521 - head/contrib/netbsd-tests/lib/libm
Message-ID:  <9E7EDF01-88C2-4CB5-B26F-1F557E4441DF@gmail.com>
In-Reply-To: <20150102185046.K943@besplex.bde.org>
References:  <201501020057.t020vf4d063191@svn.freebsd.org> <20150102185046.K943@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_EA093892-D0C9-4847-A611-887012DA5B8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Jan 2, 2015, at 0:03, Bruce Evans <brde@optusnet.com.au> wrote:

> On Fri, 2 Jan 2015, Garrett Cooper wrote:
>=20
>> Log:
>> Reset errno in :scalbnf_val and :scalbnl_val before running the tests =
so the
>> tested errno isn't stale
>=20
> It is a bug to even test errno.  No function in libm accesses errno.

I=92ll have to look again, but I=92m pretty sure NetBSD is using this to =
test errors dealing with ranges and input, and it=92s probably =
implementation dependent.

It=92s still interesting that it was setting EINVAL (errno =3D=3D 2) =
when running the tests and not others (and that potentially deserves =
investigation).

What=92s also curious is that this issue doesn=92t manifest itself on =
11-CURRENT as well, but I haven=92t taken the time to figure out why =
that is, yet (apart from having merged some revisions from head which =
didn=92t affect things), so the underlying issue is probably buried =
somewhere in another library (libc, libthr, etc).

>> This was needed in order for the test to pass on amd64 with stable/10
>>=20
>> MFC after: 3 days
>>=20
>> Modified:
>> head/contrib/netbsd-tests/lib/libm/t_scalbn.c
>>=20
>> Modified: head/contrib/netbsd-tests/lib/libm/t_scalbn.c
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> --- head/contrib/netbsd-tests/lib/libm/t_scalbn.c	Thu Jan  1 =
23:21:46 2015	(r276520)
>> +++ head/contrib/netbsd-tests/lib/libm/t_scalbn.c	Fri Jan  2 =
00:57:40 2015	(r276521)
>> @@ -225,6 +225,9 @@ ATF_TC_BODY(scalbnf_val, tc)
>> 	double rv;
>>=20
>> 	for (i =3D 0; i < tcnt; i++) {
>> +#ifdef __FreeBSD__
>> +		errno =3D 0;
>> +#endif
>=20
> This is not FreeBSD-specific.  A correct test might test
> errno under the condition (math_errhandling & MATH_ERRNO), but that
> would be a lot of work to test a fundamentally broken implementation.

It definitely isn=92t. It=92s an item that I=92ll need to bring up with =
the NetBSD folks/resolve differently in the future.

>> 		rv =3D scalbnf(tests[i].inval, tests[i].exp);
>> 		ATF_CHECK_EQ_MSG(errno, tests[i].error,
>> 		    "test %zu: errno %d instead of %d", i, errno,
>=20
> The tests might set errno elsewhere, but scalbnf() obviously doesn't
> in FreeBSD (and shouldn't unless MATH_ERRNO), so the =
ATF_CHECK_EQ_MSG()
> test can have no effect.  It is surprising that it doesn't sometimes
> fail if errno is always 0.  If it always succeeds, then tests[i].error
> must be dead data (always 0) and the ATF_CHECK_EQ_MSG() test dead code
> (always pass).

Hmmm=85 How is MATH_ERRNO supposed to work in FreeBSD. Based on =
documentation I found =97 =
http://en.cppreference.com/w/cpp/numeric/math/math_errhandling =97 it=92s =
supposed to be used for reporting errors with errno since c++11, but =
that doesn=92t seem to be implemented in libc++/libstdc++ (at least not =
based on my limited grep)? FWIW it seems like this value should be 0, =
not 1...
Thanks!

$ grep -r MATH_ERRNO contrib/binutils contrib/gcc* contrib/lib* =
contrib/llvm/ include lib sys/sys/
lib/msun/src/math.h:#define     MATH_ERRNO      1
contrib/libc++/include/cmath:    MATH_ERRNO              // C99
$

--Apple-Mail=_EA093892-D0C9-4847-A611-887012DA5B8A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUqbZwAAoJEMZr5QU6S73eXBcH/1NQf+GIElihOz9QhypYVeMs
diZH2sinafOeN0lTGk8HJemYU9Q/GaQbK4bYUj5xOxpnl9Fon5wsycs9F1HwXAqI
lYFNzsIZFbPSPjY15BAYVdP5Y8QyNWOOnV4Fzh+/SQg1PLwhXNbuOnZS1v0bAfZj
mIuUbSQ+3CtGcTfuUg2KirG0AVZ4TtEy2oDrPVX4j+KHySYpGhnicJblox1pQji6
o2T0TIvjrnXKlTq0dPRIZ8AlV28TjnTbRZ1jGXhkUJOSt8W5XZzZl0jqy+TEUqA+
+uZvIBysKfQGDrazVdwaazeMeos2xlAxbWw2+Pl7zy71G1U+nx6ky3Esqmrz4SI=
=psvE
-----END PGP SIGNATURE-----

--Apple-Mail=_EA093892-D0C9-4847-A611-887012DA5B8A--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E7EDF01-88C2-4CB5-B26F-1F557E4441DF>