NetBSD Problem Report #46433

From www@NetBSD.org  Wed May  9 03:03:54 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 7B2D463B91F
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  9 May 2012 03:03:54 +0000 (UTC)
Message-Id: <20120509030353.BC20463B915@www.NetBSD.org>
Date: Wed,  9 May 2012 03:03:53 +0000 (UTC)
From: isaki@NetBSD.org
Reply-To: isaki@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: tests/lib/libm/t_exp should not use exp() itself
X-Send-Pr-Version: www-1.0

>Number:         46433
>Category:       lib
>Synopsis:       tests/lib/libm/t_exp should not use exp() itself
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 09 03:05:00 +0000 2012
>Last-Modified:  Thu May 31 00:15:02 +0000 2012
>Originator:     Tetsuya Isaki
>Release:        NetBSD 6.0_BETA/i386
>Organization:
NetBSD
>Environment:
>Description:
The 'exp_product' test in tests/lib/libm/t_exp.c (rev1.1)
uses the following formula:
  exp(x + y) = exp(x) * exp(y)

therefore, the test code is:
  if ( exp(x+y) - (exp(x) * exp(y)) > eps )
    then it fails.

However, it is not appropriate to use exp() oneself for a test
for exp().  For example, this test will pass if a broken exp()
that always return zero.

The following tests have a similar problem as far as I found:
 - expf_product
 - exp2_product
 - exp2f_product

>How-To-Repeat:
See the source code.
>Fix:
N/A, Sorry.

>Audit-Trail:
From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 9 May 2012 08:53:41 +0300

 On Wed, May 09, 2012 at 03:05:00AM +0000, isaki@NetBSD.org wrote:
 > for exp().  For example, this test will pass if a broken exp()
 > that always return zero.

 Do you have an opinion on how to fix this (and the related issues)?

 In my opinion: if a precondition for a test is not satisfied, the test
 should be skipped. Alternatively, we could append a "broken exp(3) check"
 to these tests and record expected failures on exotic things like VAX or
 m68k without FPU. For the first option, it would be desirable to have
 machine-dependent preprocessor conditionals (cf. "_HAVE_EXP_") for each and
 every math(3) function.

 - Jukka.

From: Tetsuya Isaki <isaki@NetBSD.org>
To: gnats-bugs@NetBSD.org, jruohonen@iki.fi
Cc: lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 09 May 2012 15:07:56 +0900

 At Wed,  9 May 2012 05:55:02 +0000 (UTC),
 Jukka Ruohonen wrote:
 > The following reply was made to PR lib/46433; it has been noted by GNATS.
 :
 >  On Wed, May 09, 2012 at 03:05:00AM +0000, isaki@NetBSD.org wrote:
 >  > for exp().  For example, this test will pass if a broken exp()
 >  > that always return zero.
 >  
 >  Do you have an opinion on how to fix this (and the related issues)?
 >     
 >  In my opinion: if a precondition for a test is not satisfied, the test
 >  should be skipped. Alternatively, we could append a "broken exp(3) check"
 >  to these tests and record expected failures on exotic things like VAX or
 >  m68k without FPU. For the first option, it would be desirable to have
 >  machine-dependent preprocessor conditionals (cf. "_HAVE_EXP_") for each and
 >  every math(3) function.

 How about the method to compare with the pre-calculated
 constants (like cos_angles test in t_cos.c)?
 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Tue, 29 May 2012 14:46:21 +0300

 On Wed, May 09, 2012 at 06:10:05AM +0000, Tetsuya Isaki wrote:
 >  How about the method to compare with the pre-calculated
 >  constants (like cos_angles test in t_cos.c)?

 That is one option sure. But if there is no immedate fix available, we
 likely want to count these cases as expected failures. So I think we can put
 something like the following to the beginning of these cases:

 	if (exp(1.0) == 0.0) {
 		atf_tc_expect_fail("PR lib/46433");
 		atf_tc_fail("exp(1.0) = 0.0");
 	}

 	[start the actual test]

 - Jukka.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: jruohonen@iki.fi, isaki@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 19:09:40 +0900

 >  That is one option sure. But if there is no immedate fix available, we
 >  likely want to count these cases as expected failures. So I think we can put
 >  something like the following to the beginning of these cases:
 >  
 >  	if (exp(1.0) == 0.0) {
 >  		atf_tc_expect_fail("PR lib/46433");
 >  		atf_tc_fail("exp(1.0) = 0.0");
 >  	}
 >  
 >  	[start the actual test]

 The point of this PR is not that there is a particular implementation
 which is expected to fail on this test, but simply "this test is wrong"
 (it isn't an actual test), because it could return false positive
 even if the exp() function has obviously bogus implementation.
 (if exp() always returns zero for example, as noted in the PR)

 Testes for arithmetic functions should also have checks against
 a set of "correct" result values with acceptable tolerance like t_cos,
 as submitter says.  Why can't it be an "immediate" fix?

 ---
 Izumi Tsutsui

From: Tetsuya Isaki <isaki@pastel-flower.jp>
To: gnats-bugs@NetBSD.org, jruohonen@iki.fi
Cc: lib-bug-people@netbsd.org,
	gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 23:15:28 +0900

 At Tue, 29 May 2012 11:50:04 +0000 (UTC),
 Jukka Ruohonen wrote:
 >  That is one option sure. But if there is no immedate fix available, we
 >  likely want to count these cases as expected failures. So I think we can put
 >  something like the following to the beginning of these cases:
 >  
 >  	if (exp(1.0) == 0.0) {
 >  		atf_tc_expect_fail("PR lib/46433");
 >  		atf_tc_fail("exp(1.0) = 0.0");
 >  	}
 >  
 >  	[start the actual test]

 How about this?  (At first I rewrote about exp()/expf()
 because I don't know about exp2()/exp2f() well...)
 However, I'm not sure about its appropriate range and
 appropriate epsilon.

 Index: t_exp.c
 ===================================================================
 RCS file: /cvsroot/src/tests/lib/libm/t_exp.c,v
 retrieving revision 1.1
 diff -u -r1.1 t_exp.c
 --- t_exp.c	18 Sep 2011 05:19:18 -0000	1.1
 +++ t_exp.c	30 May 2012 14:09:56 -0000
 @@ -32,6 +32,22 @@
  #include <atf-c.h>
  #include <math.h>

 +/* y = exp(x) */
 +static const struct {
 +	double x;
 +	double y;
 +} exp_values[] = {
 +	{  -10, 0.4539992976248485e-4, },
 +	{   -5, 0.6737946999085467e-2, },
 +	{   -1, 0.3678794411714423, },
 +	{ -0.1, 0.9048374180359595, },
 +	{    0, 1.0000000000000000, },
 +	{  0.1, 1.1051709180756477, },
 +	{    1, 2.7182818284590452, },
 +	{    5, 148.41315910257660, },
 +	{   10, 22026.465794806718, },
 +};
 +
  /*
   * exp2(3)
   */
 @@ -305,22 +321,23 @@
  ATF_TC(exp_product);
  ATF_TC_HEAD(exp_product, tc)
  {
 -	atf_tc_set_md_var(tc, "descr", "Test exp(x + y) == exp(x) * exp(y)");
 +	atf_tc_set_md_var(tc, "descr", "Test some selected exp(x)");
  }

  ATF_TC_BODY(exp_product, tc)
  {
  #ifndef __vax__
 -	const double x[] = { 0.0, 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8 };
 -	const double y[] = { 8.8, 7.7, 6.6, 5.5, 4.4, 3.3, 2.2, 1.1, 0.0 };
 +	double x;
 +	double y;
  	const double eps = 1.0e-11;
  	size_t i;

 -	for (i = 0; i < __arraycount(x); i++) {
 +	for (i = 0; i < __arraycount(exp_values); i++) {
 +		x = exp_values[i].x;
 +		y = exp_values[i].y;

 -		if (fabs(exp(x[i] + y[i]) - (exp(x[i]) * exp(y[i]))) > eps)
 -			atf_tc_fail_nonfatal("exp(%0.01f + %0.01f) != exp("
 -			    "%0.01f) * exp(%0.01f)", x[i], y[i], x[i], y[i]);
 +		if (fabs(exp(x) - y) > eps)
 +			atf_tc_fail_nonfatal("exp(%0.01f) != %18.18e", x, y);
  	}
  #endif
  }
 @@ -413,22 +430,23 @@
  ATF_TC(expf_product);
  ATF_TC_HEAD(expf_product, tc)
  {
 -	atf_tc_set_md_var(tc, "descr", "Test expf(x+y) == expf(x) * expf(y)");
 +	atf_tc_set_md_var(tc, "descr", "Test some selected expf(x)");
  }

  ATF_TC_BODY(expf_product, tc)
  {
  #ifndef __vax__
 -	const float x[] = { 0.0, 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8 };
 -	const float y[] = { 8.8, 7.7, 6.6, 5.5, 4.4, 3.3, 2.2, 1.1, 0.0 };
 +	float x;
 +	float y;
  	const float eps = 1.0e-2;
  	size_t i;

 -	for (i = 0; i < __arraycount(x); i++) {
 +	for (i = 0; i < __arraycount(exp_values); i++) {
 +		x = exp_values[i].x;
 +		y = exp_values[i].y;

 -		if (fabsf(expf(x[i] + y[i]) - (expf(x[i]) * expf(y[i]))) > eps)
 -			atf_tc_fail_nonfatal("expf(%0.01f + %0.01f) != expf("
 -			    "%0.01f) * expf(%0.01f)", x[i], y[i], x[i], y[i]);
 +		if (fabsf(expf(x) - y) > eps)
 +			atf_tc_fail_nonfatal("expf(%0.01f) != %18.18e", x, y);
  	}
  #endif
  }

 ---
 Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 17:19:39 +0300

 On Wed, May 30, 2012 at 11:15:28PM +0900, Tetsuya Isaki wrote:
 > because I don't know about exp2()/exp2f() well...)
 > However, I'm not sure about its appropriate range and
 > appropriate epsilon.

 Looks good! Thanks for doing this.

 To Tsutsui: by immediate fix I mean that exp(3) (and maybe others?) are
 still completely broken on this architecture, with or without a test. I am
 not sure why systems without FPU even allow libm(3) or expose functions from
 there...

 - Jukka.

 > 
 > Index: t_exp.c
 > ===================================================================
 > RCS file: /cvsroot/src/tests/lib/libm/t_exp.c,v
 > retrieving revision 1.1
 > diff -u -r1.1 t_exp.c
 > --- t_exp.c	18 Sep 2011 05:19:18 -0000	1.1
 > +++ t_exp.c	30 May 2012 14:09:56 -0000
 > @@ -32,6 +32,22 @@
 >  #include <atf-c.h>
 >  #include <math.h>
 >  
 > +/* y = exp(x) */
 > +static const struct {
 > +	double x;
 > +	double y;
 > +} exp_values[] = {
 > +	{  -10, 0.4539992976248485e-4, },
 > +	{   -5, 0.6737946999085467e-2, },
 > +	{   -1, 0.3678794411714423, },
 > +	{ -0.1, 0.9048374180359595, },
 > +	{    0, 1.0000000000000000, },
 > +	{  0.1, 1.1051709180756477, },
 > +	{    1, 2.7182818284590452, },
 > +	{    5, 148.41315910257660, },
 > +	{   10, 22026.465794806718, },
 > +};
 > +
 >  /*
 >   * exp2(3)
 >   */
 > @@ -305,22 +321,23 @@
 >  ATF_TC(exp_product);
 >  ATF_TC_HEAD(exp_product, tc)
 >  {
 > -	atf_tc_set_md_var(tc, "descr", "Test exp(x + y) == exp(x) * exp(y)");
 > +	atf_tc_set_md_var(tc, "descr", "Test some selected exp(x)");
 >  }
 >  
 >  ATF_TC_BODY(exp_product, tc)
 >  {
 >  #ifndef __vax__
 > -	const double x[] = { 0.0, 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8 };
 > -	const double y[] = { 8.8, 7.7, 6.6, 5.5, 4.4, 3.3, 2.2, 1.1, 0.0 };
 > +	double x;
 > +	double y;
 >  	const double eps = 1.0e-11;
 >  	size_t i;
 >  
 > -	for (i = 0; i < __arraycount(x); i++) {
 > +	for (i = 0; i < __arraycount(exp_values); i++) {
 > +		x = exp_values[i].x;
 > +		y = exp_values[i].y;
 >  
 > -		if (fabs(exp(x[i] + y[i]) - (exp(x[i]) * exp(y[i]))) > eps)
 > -			atf_tc_fail_nonfatal("exp(%0.01f + %0.01f) != exp("
 > -			    "%0.01f) * exp(%0.01f)", x[i], y[i], x[i], y[i]);
 > +		if (fabs(exp(x) - y) > eps)
 > +			atf_tc_fail_nonfatal("exp(%0.01f) != %18.18e", x, y);
 >  	}
 >  #endif
 >  }
 > @@ -413,22 +430,23 @@
 >  ATF_TC(expf_product);
 >  ATF_TC_HEAD(expf_product, tc)
 >  {
 > -	atf_tc_set_md_var(tc, "descr", "Test expf(x+y) == expf(x) * expf(y)");
 > +	atf_tc_set_md_var(tc, "descr", "Test some selected expf(x)");
 >  }
 >  
 >  ATF_TC_BODY(expf_product, tc)
 >  {
 >  #ifndef __vax__
 > -	const float x[] = { 0.0, 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8 };
 > -	const float y[] = { 8.8, 7.7, 6.6, 5.5, 4.4, 3.3, 2.2, 1.1, 0.0 };
 > +	float x;
 > +	float y;
 >  	const float eps = 1.0e-2;
 >  	size_t i;
 >  
 > -	for (i = 0; i < __arraycount(x); i++) {
 > +	for (i = 0; i < __arraycount(exp_values); i++) {
 > +		x = exp_values[i].x;
 > +		y = exp_values[i].y;
 >  
 > -		if (fabsf(expf(x[i] + y[i]) - (expf(x[i]) * expf(y[i]))) > eps)
 > -			atf_tc_fail_nonfatal("expf(%0.01f + %0.01f) != expf("
 > -			    "%0.01f) * expf(%0.01f)", x[i], y[i], x[i], y[i]);
 > +		if (fabsf(expf(x) - y) > eps)
 > +			atf_tc_fail_nonfatal("expf(%0.01f) != %18.18e", x, y);
 >  	}
 >  #endif
 >  }
 > 
 > ---
 > Tetsuya Isaki <isaki@pastel-flower.jp / isaki@NetBSD.org>

From: Martin Husemann <martin@duskware.de>
To: Tetsuya Isaki <isaki@pastel-flower.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 16:35:56 +0200

 Side note: the exp_product test should not have a #ifndef __vax__.
 I'm not sure about the ifndef around the inf tests, the one around exp2_nan
 and exp2_zero_neg are correct. (VAX does not have NAN nor +/- zero).

 Martin

From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46433 CVS commit: src/tests/lib/libm
Date: Wed, 30 May 2012 15:14:11 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Wed May 30 15:14:11 UTC 2012

 Modified Files:
 	src/tests/lib/libm: t_exp.c

 Log Message:
 Add patch from Tetsuya Isaki in PR lib/46433.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 src/tests/lib/libm/t_exp.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: jruohonen@iki.fi
Cc: gnats-bugs@NetBSD.org, isaki@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Thu, 31 May 2012 00:23:05 +0900

 >  To Tsutsui: by immediate fix I mean that exp(3) (and maybe others?) are
 >  still completely broken on this architecture, with or without a test. I am
 >  not sure why systems without FPU even allow libm(3) or expose functions from
 >  there...

 exp(3) in src/lib/libm/arch/mc68881 is not broken.
 FPU emulator in src/sys/arch/m68k/fpe is still in progress.
 Users who need immediate fix could use MKSOFTFLOAT environment.
 Current tests are not useful with or without correct FP implementation
 because they could return false positive, and skipping tests doesn't
 help users (and developers) at all.

 It's much better if libm tests can be used to check kernel
 FPE implementation, because m68k FPU has exponetial (and logarithm,
 hyperboric, trigonometric etc.) instructions and MD libm functions
 directly call them:
 http://nxr.netbsd.org/xref/src/lib/libm/arch/mc68881/e_exp.S#43
 That's the point of this PR.

 ---
 Izumi Tsutsui

From: Jukka Ruohonen <jruohonen@iki.fi>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org, isaki@NetBSD.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 18:32:27 +0300

 On Thu, May 31, 2012 at 12:23:05AM +0900, Izumi Tsutsui wrote:
 > Current tests are not useful with or without correct FP implementation
 > because they could return false positive, and skipping tests doesn't
 > help users (and developers) at all.

 Don't be so pessimistic; otherwise you have the burden to point out the
 specific cases where "current tests are not useful".

 And once again, the idea has never been to skip tests but to report these
 as expected failures. As a developer, you should benefit from this as you
 see directly whether and when a bug is fixed. Thus, this particular case
 still requires the MD-specific check, which points to this PR upon failure.

 - Jukka.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: jruohonen@iki.fi
Cc: gnats-bugs@NetBSD.org, isaki@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Thu, 31 May 2012 00:47:10 +0900

 > And once again, the idea has never been to skip tests but to report these
 > as expected failures. As a developer, you should benefit from this as you
 > see directly whether and when a bug is fixed. Thus, this particular case
 > still requires the MD-specific check, which points to this PR upon failure.

 Only if the test correctly fails on bogus implementation?

 Tests which could return false positive won't show if a bug is fixed
 and just hide bugs.

 ---
 Izumi Tsutsui

From: Jukka Ruohonen <jruohonen@iki.fi>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 18:57:08 +0300

 On Thu, May 31, 2012 at 12:47:10AM +0900, Izumi Tsutsui wrote:
 > > And once again, the idea has never been to skip tests but to report these
 > > as expected failures. As a developer, you should benefit from this as you
 > > see directly whether and when a bug is fixed. Thus, this particular case
 > > still requires the MD-specific check, which points to this PR upon failure.
 > 
 > Only if the test correctly fails on bogus implementation?
 >
 > Tests which could return false positive won't show if a bug is fixed
 > and just hide bugs.

 Obviously. No one has claimed that there wouldn't be bugs in the tests. For
 this case, there is still the twin PR lib/46434.

 But when trying to see the forest from the trees: the decision is not always
 clear particularly when emulators come to the picture. For instance, we've
 captured a fair amount of Qemu-related FP bugs. But now that these are
 counted as expected failures, we've noticed that new Qemu releases have
 fixed some of these issues; see PR misc/44767.

 And I don't particularly like the current #ifdef __vax__ madness either...

 - Jukka.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, isaki@NetBSD.org
Cc: 
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 14:36:21 -0400

 On May 30,  4:00pm, jruohonen@iki.fi (Jukka Ruohonen) wrote:
 -- Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself

 | The following reply was made to PR lib/46433; it has been noted by GNATS.
 | 
 | From: Jukka Ruohonen <jruohonen@iki.fi>
 | To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 | Cc: gnats-bugs@NetBSD.org
 | Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
 | Date: Wed, 30 May 2012 18:57:08 +0300
 | 
 |  On Thu, May 31, 2012 at 12:47:10AM +0900, Izumi Tsutsui wrote:
 |  > > And once again, the idea has never been to skip tests but to report these
 |  > > as expected failures. As a developer, you should benefit from this as you
 |  > > see directly whether and when a bug is fixed. Thus, this particular case
 |  > > still requires the MD-specific check, which points to this PR upon failure.
 |  > 
 |  > Only if the test correctly fails on bogus implementation?
 |  >
 |  > Tests which could return false positive won't show if a bug is fixed
 |  > and just hide bugs.
 |  
 |  Obviously. No one has claimed that there wouldn't be bugs in the tests. For
 |  this case, there is still the twin PR lib/46434.
 |  
 |  But when trying to see the forest from the trees: the decision is not always
 |  clear particularly when emulators come to the picture. For instance, we've
 |  captured a fair amount of Qemu-related FP bugs. But now that these are
 |  counted as expected failures, we've noticed that new Qemu releases have
 |  fixed some of these issues; see PR misc/44767.
 |  
 |  And I don't particularly like the current #ifdef __vax__ madness either...

 That should be changed to HAVE_IEEE_MATH or something. I think I started
 doing that a while ago.

 christos

From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 20:38:35 +0200

 On Wed, May 30, 2012 at 02:36:21PM -0400, Christos Zoulas wrote:
 > That should be changed to HAVE_IEEE_MATH or something. I think I started
 > doing that a while ago.

 Yes, but only with review - some should be removed.

 Martin

From: christos@zoulas.com (Christos Zoulas)
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself
Date: Wed, 30 May 2012 14:53:02 -0400

 On May 30,  8:38pm, martin@duskware.de (Martin Husemann) wrote:
 -- Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself

 | On Wed, May 30, 2012 at 02:36:21PM -0400, Christos Zoulas wrote:
 | > That should be changed to HAVE_IEEE_MATH or something. I think I started
 | > doing that a while ago.
 | 
 | Yes, but only with review - some should be removed.

 Absolutely. I would also see added guidelines on what to do with the non-ieee
 case. I.e. when the dynamic range does not fit, or when there is lack of
 inf/nan, and how to deal with signalling.

 christos

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: [jruohonen@iki.fi: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself]
Date: Thu, 31 May 2012 00:19:18 +0300

 On Wed, May 30, 2012 at 02:36:21PM -0400, Christos Zoulas wrote:
 > That should be changed to HAVE_IEEE_MATH or something. I think I started
 > doing that a while ago.

 I welcome anything going into this direction. However, we have also cases
 such as:

 #if defined(__i386__) || defined(__amd64__) || defined(__sparc__)

 for some FP variants such as fenv(3). C99-compliant things like tgmath(3)
 probably provide more examples.

 So, say, if I would be deploying an application for NetBSD, I would perhaps
 appreciate simple _HAVE-style preprocessor conditionals.

 - Jukka.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself]]
Date: Thu, 31 May 2012 00:24:33 +0300

 On Wed, May 30, 2012 at 02:36:21PM -0400, Christos Zoulas wrote:
 > That should be changed to HAVE_IEEE_MATH or something. I think I started
 > doing that a while ago.

 I welcome anything going into this direction. However, we have also cases
 such as:

 #if defined(__i386__) || defined(__amd64__) || defined(__sparc__)

 for some FP variants such as fenv(3). C99-compliant things like tgmath(3)
 probably provide more examples.

 So, say, if I would be deploying an application for NetBSD, I would perhaps
 appreciate simple _HAVE-style preprocessor conditionals.

 - Jukka.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, isaki@NetBSD.org
Cc: 
Subject: Re: [jruohonen@iki.fi: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself]
Date: Wed, 30 May 2012 20:12:16 -0400

 On May 30,  9:20pm, jruohonen@iki.fi (Jukka Ruohonen) wrote:
 -- Subject: [jruohonen@iki.fi: Re: lib/46433: tests/lib/libm/t_exp should not

 | The following reply was made to PR lib/46433; it has been noted by GNATS.
 | 
 | From: Jukka Ruohonen <jruohonen@iki.fi>
 | To: gnats-bugs@NetBSD.org
 | Cc: 
 | Subject: [jruohonen@iki.fi: Re: lib/46433: tests/lib/libm/t_exp should not use exp() itself]
 | Date: Thu, 31 May 2012 00:19:18 +0300
 | 
 |  On Wed, May 30, 2012 at 02:36:21PM -0400, Christos Zoulas wrote:
 |  > That should be changed to HAVE_IEEE_MATH or something. I think I started
 |  > doing that a while ago.
 |  
 |  I welcome anything going into this direction. However, we have also cases
 |  such as:
 |  
 |  #if defined(__i386__) || defined(__amd64__) || defined(__sparc__)
 |  
 |  for some FP variants such as fenv(3). C99-compliant things like tgmath(3)
 |  probably provide more examples.
 |  
 |  So, say, if I would be deploying an application for NetBSD, I would perhaps
 |  appreciate simple _HAVE-style preprocessor conditionals.
 |  

 Yes, we need __HAVE_FENV etc.

 christos

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.