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
(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.
Home