Re: CVS commit: src/tests/lib/libm

2017-08-21 Thread Joerg Sonnenberger
On Mon, Aug 21, 2017 at 01:11:18PM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Mon Aug 21 17:11:18 UTC 2017
> 
> Modified Files:
>   src/tests/lib/libm: t_fe_round.c
> 
> Log Message:
> don't skip nexttoward for aarch64 and mips64

Thanks.

Joerg


Re: CVS commit: src/tests/lib/libm

2017-08-21 Thread Joerg Sonnenberger
On Mon, Aug 21, 2017 at 10:02:44AM +, Christos Zoulas wrote:
> In article <20170820110132.ga5...@britannica.bec.de>,
> Joerg Sonnenberger   wrote:
> >On Sun, Aug 20, 2017 at 04:25:47AM -0400, Christos Zoulas wrote:
> >> Module Name:   src
> >> Committed By:  christos
> >> Date:  Sun Aug 20 08:25:47 UTC 2017
> >> 
> >> Modified Files:
> >>src/tests/lib/libm: t_fe_round.c
> >> 
> >> Log Message:
> >> fix build (missing nexttoward on mips64 and aarch64)
> >
> >Please fix the actual problem and not just paper over it.
> 
> I am not papering over it. It is now a test failure not a build failure.
> The build can now proceed and we can actually fix more build/test failures.
> This has been broken for more than a week. It is the responsibility
> of the person who broke the build to fix it. You are shooting the messenger.

The problem with test failures is that they are not visible. Build
failures at least are, if they make sense. I don't understand many of
the current llvm build failures at all nor did I see mips64 and aarch64
recently, given that the latter moved...

Joerg


Re: CVS commit: src/tests/lib/libm

2017-08-21 Thread Christos Zoulas
In article <20170820110132.ga5...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Sun, Aug 20, 2017 at 04:25:47AM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Aug 20 08:25:47 UTC 2017
>> 
>> Modified Files:
>>  src/tests/lib/libm: t_fe_round.c
>> 
>> Log Message:
>> fix build (missing nexttoward on mips64 and aarch64)
>
>Please fix the actual problem and not just paper over it.

I am not papering over it. It is now a test failure not a build failure.
The build can now proceed and we can actually fix more build/test failures.
This has been broken for more than a week. It is the responsibility
of the person who broke the build to fix it. You are shooting the messenger.

christos



Re: CVS commit: src/tests/lib/libm

2017-08-20 Thread Joerg Sonnenberger
On Sun, Aug 20, 2017 at 04:25:47AM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun Aug 20 08:25:47 UTC 2017
> 
> Modified Files:
>   src/tests/lib/libm: t_fe_round.c
> 
> Log Message:
> fix build (missing nexttoward on mips64 and aarch64)

Please fix the actual problem and not just paper over it.

Joerg


Re: CVS commit: src/tests/lib/libm

2017-07-26 Thread Taylor R Campbell
> Date: Wed, 26 Jul 2017 22:02:09 +0300
> From: Valery Ushakov 
> 
> Also, portmasters could have been asked in advance, at least pro
> forma.  If I'm given a heads up and a summary of what needs to be
> done, I can usually schedule it within a few days.  When I see a
> commit out of the blue that breaks several ports, I naturally assume
> the author might not have relaized they are breaking things.  Stuff
> like that happens, no big deal.  And then it's safer to revert the
> commit temporarily than to second-guess.

Fair enough -- my apologies for the churn.  In this I expect the fix
should be easy for anyone who is comfortable making port-specific
changes on the ports whose builds were broken.

> If I know *what* about sparc and sh3? :)
> 
> I'm happily clueless about libm.  If nobody tells me what they want, I
> can't help.  Also, with all the hand-wringing about our libm being
> completely broken I'd expect there's at least a high-level summary of
> what is broken or missing.  Or would you rather spring those surprises
> on us one function at a time? :)

he@ noticed that nearbyint was missing on macppc.  We don't have a
comprehensive test suite for libm -- we're incrementally working
toward one, and this is one step.

In this case, the only question is: will s_nearbyint.c work for the
floating-point representation on sparc and sh3?  I assume they use
IEEE 754 like everyone else on the planet except VAX, so the answer is
almost certainly `yes'.  If so, the only work is to edit the libm
Makefile to include s_nearbyint.c on those platforms.


Re: CVS commit: src/tests/lib/libm

2017-07-26 Thread Joerg Sonnenberger
On Wed, Jul 26, 2017 at 06:28:16AM +0700, Robert Elz wrote:
> Date:Tue, 25 Jul 2017 22:43:18 +
> From:co...@sdf.org
> Message-ID:  <20170725224318.ga3...@sdf.org>
> 
>   | It's a minor inconvenience to fix a critical bug.
> 
> Breaking builds is not a minor inconvenience, it can cause all
> progress to halt for developers who keep their tree up to date all
> the time.

I recommented the same action and in this case, I consider it "expose
the bugs in a way that are easy to find". No, the tree shouldn't be left
broken for any non-trivial amount of time, but we also don't have a good
way to do pre-commit testing for patches across all architectures
either. As such, I find *this* specific case an acceptable way of
exposing the breakage.

> While build breakages cannot always be avoided, you can generally
> expect someone to "fix" a breakage you have caused if you don't
> correct it within a few hours - where "fix" might mean reverting
> your change, or doing almost anything else to allow the build to
> succeed.

Keep in mind that even just waiting for a HEAD build typically takes a
couple of hours.

Joerg


Re: CVS commit: src/tests/lib/libm

2017-07-26 Thread Valery Ushakov
On Wed, Jul 26, 2017 at 03:24:16 +, Taylor R Campbell wrote:

> > Date: Wed, 26 Jul 2017 00:31:48 +0300
> > From: Valery Ushakov 
> > 
> > On Tue, Jul 25, 2017 at 21:29:33 +, co...@sdf.org wrote:
> > > On Tue, Jul 25, 2017 at 09:26:56PM +, Valeriy E. Ushakov wrote:
> > > > Revert previous as it breaks at least sparc and hpcsh builds.
> > > > nearbyint() is not included in libm on all platforms.
> > > 
> > > The intention was to find which platforms do not install it and change
> > > them to install it
> > 
> > You can do that in your tree, not in the public repo.
> 
> I suggested to he@ that he commit this so we can quickly find which
> platforms have obviously broken libm, since nobody at the time had the
> resources to try every platform locally.

Get representative base.tgz extract libm and do nm on it on ~anything?
You don't even need tools built for that.

Also, portmasters could have been asked in advance, at least pro
forma.  If I'm given a heads up and a summary of what needs to be
done, I can usually schedule it within a few days.  When I see a
commit out of the blue that breaks several ports, I naturally assume
the author might not have relaized they are breaking things.  Stuff
like that happens, no big deal.  And then it's safer to revert the
commit temporarily than to second-guess.


> If you know about sparc and/or hpcsh, can you fix them by adding the
> right source file in the appropriate place in the libm Makefile?

If I know *what* about sparc and sh3? :)

I'm happily clueless about libm.  If nobody tells me what they want, I
can't help.  Also, with all the hand-wringing about our libm being
completely broken I'd expect there's at least a high-level summary of
what is broken or missing.  Or would you rather spring those surprises
on us one function at a time? :)

-uwe


Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread Robert Elz
Date:Wed, 26 Jul 2017 00:17:49 +
From:co...@sdf.org
Message-ID:  <20170726001748.gd3...@sdf.org>

  | And it adds an actual test for functionality, to be sure we weren't
  | wrong in adding the function for that arch.

That's useful, but you can get that if you compile, and run, the program
as part of the test, rather than compiling as part of the build.

And of course. if on all of those less commonly used architectures where
no-one (apparently) ever runs tests, you don't get that benefit.

kre



Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread coypu
There is no other way to find and fix these problems. nobody runs sh3
tests, and non-x86 ports have so many failures that it's going to be
drowned in the noise.

And it adds an actual test for functionality, to be sure we weren't
wrong in adding the function for that arch.

This is causing packages to fail in a way that cannot be fixed in an
existing release.


Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread Robert Elz
Date:Tue, 25 Jul 2017 22:43:18 +
From:co...@sdf.org
Message-ID:  <20170725224318.ga3...@sdf.org>

  | It's a minor inconvenience to fix a critical bug.

Breaking builds is not a minor inconvenience, it can cause all
progress to halt for developers who keep their tree up to date all
the time.

While build breakages cannot always be avoided, you can generally
expect someone to "fix" a breakage you have caused if you don't
correct it within a few hours - where "fix" might mean reverting
your change, or doing almost anything else to allow the build to
succeed.

If I had been affected by this, my solution would probably have been
to make a dummy function in libm so the program would link, and perhaps
even to look in the test, see what result was expected, and simply
return that as a constant, so the test "works" as well.

What's more, exotic interfaces in libm are, almost by definition,
not critical bugs.   Stuff that should be supported, should be
supported, but if 99% of the applications will work fine without it,
then adding it is hardly anything time critical.

kre



Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread coypu
On Wed, Jul 26, 2017 at 05:32:42AM +0700, Robert Elz wrote:
> Date:Wed, 26 Jul 2017 00:31:48 +0300
> From:Valery Ushakov 
> Message-ID:  <20170725213148.ga16...@pony.stderr.spb.ru>
> 
>   | You can do that in your tree, not in the public repo.
> 
> coypu - an alternative would be to make a test that (when run as a test,
> rather than when being built) attempts to compile code to use whatever
> interface that is, so that the test fails if the interface doesn't exist,
> rather than actually breaking the build, if the test cannot be compiled and
> installed.

It's a minor inconvenience to fix a critical bug.
we have a lot more of those, as libm's makefile is a trainwreck.


Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread Robert Elz
Date:Wed, 26 Jul 2017 00:31:48 +0300
From:Valery Ushakov 
Message-ID:  <20170725213148.ga16...@pony.stderr.spb.ru>

  | You can do that in your tree, not in the public repo.

coypu - an alternative would be to make a test that (when run as a test,
rather than when being built) attempts to compile code to use whatever
interface that is, so that the test fails if the interface doesn't exist,
rather than actually breaking the build, if the test cannot be compiled and
installed.

kre



Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread Valery Ushakov
On Tue, Jul 25, 2017 at 21:29:33 +, co...@sdf.org wrote:

> On Tue, Jul 25, 2017 at 09:26:56PM +, Valeriy E. Ushakov wrote:
> > Module Name:src
> > Committed By:   uwe
> > Date:   Tue Jul 25 21:26:56 UTC 2017
> > 
> > Modified Files:
> > src/tests/lib/libm: t_fe_round.c
> > 
> > Log Message:
> > Revert previous as it breaks at least sparc and hpcsh builds.
> > nearbyint() is not included in libm on all platforms.
> 
> The intention was to find which platforms do not install it and change
> them to install it

You can do that in your tree, not in the public repo.

-uwe


Re: CVS commit: src/tests/lib/libm

2017-07-25 Thread coypu
On Tue, Jul 25, 2017 at 09:26:56PM +, Valeriy E. Ushakov wrote:
> Module Name:  src
> Committed By: uwe
> Date: Tue Jul 25 21:26:56 UTC 2017
> 
> Modified Files:
>   src/tests/lib/libm: t_fe_round.c
> 
> Log Message:
> Revert previous as it breaks at least sparc and hpcsh builds.
> nearbyint() is not included in libm on all platforms.

The intention was to find which platforms do not install it and change
them to install it


Re: CVS commit: src/tests/lib/libm

2016-12-19 Thread coypu
On Mon, Dec 19, 2016 at 05:44:56PM +, co...@sdf.org wrote:
> I suppose the name is dumb, but I only thought about it
> after committing. sorry.
> It should crash with SIGFPE on alpha, which is why I thought
> of exceptions when naming it!

... except it shouldn't do that either now.
I'm gonna stop talking now


Re: CVS commit: src/tests/lib/libm

2016-12-19 Thread coypu
On Mon, Dec 19, 2016 at 05:38:24PM +, Maya Rashish wrote:
> Module Name:  src
> Committed By: maya
> Date: Mon Dec 19 17:38:24 UTC 2016
> 
> Modified Files:
>   src/tests/lib/libm: Makefile
> Added Files:
>   src/tests/lib/libm: t_fe_round.c
> 
> Log Message:
> add test for fesetround/fegetround that uses lrint (and tests it a bunch).
> It doesn't fail on amd64.
> 

I suppose the name is dumb, but I only thought about it
after committing. sorry.
It should crash with SIGFPE on alpha, which is why I thought
of exceptions when naming it!


Re: CVS commit: src/tests/lib/libm

2015-01-29 Thread Tetsuya Isaki
At Sat, 24 Jan 2015 10:35:01 +,
David Laight wrote:
Log Message:
In the exp2_values test case, provide separate expected return values
for the float case, reflecting the actual exp2f() argument value after
rounding to float precision.  Fixes PR lib/49256.  Thanks to Makoto
Kamada and Tetsuya Isaki for the analysis.
   
   The reason I left the tests failing is that the results should be more
   accurate than the values that are actually returned.
   
   Changing the 'expected' values so that the tests pass is just wrong.
 ...
   I think the values ought to be accurate to one or two counts on the lsb
   of the mantissa.
  
  It is not an acuuracy problem of result, is an implicit type cast
  problem of argument.
  
  exp2()'s argument is double and exp2f()'s is float.
  
  As you know,
  exp2(7.7) means exp2((double)7.7) and
  exp2f(7.7) means exp2f((float)7.7).
  
  (double)7.7 = 0x1.ecccdp+2 in %a format
  (float)7.7  = 0x1.ecp+2 in %a format
 
 I'd forgetten to allow for that difference, and the change didn't
 mention it either.
 I'd expect (double)exp2f(f) to differ from exp2((double)f) by only
 1 or 2 counts in the mantissa. You definitely want to use the
 lattet calculation to get the check value.
 
 It is 'interesting' that (float)7.7 gets truncated rather than
 rounded. I'd expect 7.7f to be 0x1edp+2, which would bring
 the result into the old bounds.

%a's mantissa for float is 24 bit long (6 digit hex), but
float's mantissa is 23 bit long.  Therefore the LSB of this
format is 'invalid' bit, not 'valid and zero'.

(On the other hand, double's mantissa is 52 bit and 13 digit
hex of %a format is also 54 bit.  double does not have such
a trailing invalid bit.)

7.7 is represented as 0x1.ecc...p+2.
In float, ULP=0 Guard=0 as below, so it is truncated.

 bit 1720  2124  25
  ... 1 1 0 0   1 1 0 0   1 1 0 0 ...
^ ^   ^
  ULP G   R S

In double, on the other hand, ULP=0 Guard=1 and Round=1, so
it is rounded up.

 bit 4750  5154  55
  ... 1 1 0 0   1 1 0 0   1 1 0 0 ...
  ^   ^ ^
 ULP  G R S
---
Tetsuya Isaki is...@pastel-flower.jp / is...@netbsd.org


Re: CVS commit: src/tests/lib/libm

2015-01-24 Thread David Laight
On Wed, Jan 21, 2015 at 10:09:55PM +0900, Tetsuya Isaki wrote:
 At Wed, 15 Oct 2014 19:48:53 +0100,
 David Laight wrote:
   
   Log Message:
   In the exp2_values test case, provide separate expected return values
   for the float case, reflecting the actual exp2f() argument value after
   rounding to float precision.  Fixes PR lib/49256.  Thanks to Makoto
   Kamada and Tetsuya Isaki for the analysis.
  
  The reason I left the tests failing is that the results should be more
  accurate than the values that are actually returned.
  
  Changing the 'expected' values so that the tests pass is just wrong.
...
  I think the values ought to be accurate to one or two counts on the lsb
  of the mantissa.
 
 It is not an acuuracy problem of result, is an implicit type cast
 problem of argument.
 
 exp2()'s argument is double and exp2f()'s is float.
 
 As you know,
 exp2(7.7) means exp2((double)7.7) and
 exp2f(7.7) means exp2f((float)7.7).
 
 (double)7.7 = 0x1.ecccdp+2 in %a format
 (float)7.7  = 0x1.ecp+2 in %a format

I'd forgetten to allow for that difference, and the change didn't
mention it either.
I'd expect (double)exp2f(f) to differ from exp2((double)f) by only
1 or 2 counts in the mantissa. You definitely want to use the
lattet calculation to get the check value.

It is 'interesting' that (float)7.7 gets truncated rather than
rounded. I'd expect 7.7f to be 0x1edp+2, which would bring
the result into the old bounds.

David

-- 
David Laight: da...@l8s.co.uk


Re: CVS commit: src/tests/lib/libm

2015-01-21 Thread Tetsuya Isaki
At Wed, 15 Oct 2014 19:48:53 +0100,
David Laight wrote:
  Module Name:src
  Committed By:   gson
  Date:   Tue Oct  7 16:53:44 UTC 2014
  
  Modified Files:
  src/tests/lib/libm: t_exp.c
  
  Log Message:
  In the exp2_values test case, provide separate expected return values
  for the float case, reflecting the actual exp2f() argument value after
  rounding to float precision.  Fixes PR lib/49256.  Thanks to Makoto
  Kamada and Tetsuya Isaki for the analysis.
 
 The reason I left the tests failing is that the results should be more
 accurate than the values that are actually returned.
 
 Changing the 'expected' values so that the tests pass is just wrong.
 
 What I should have got araound to doing is using the x87 instruction
 to generate accurate 64bit mantissa (long double) results for the
 values, and then looked at the sizes of the error terms.
 
 I think the values ought to be accurate to one or two counts on the lsb
 of the mantissa.

It is not an acuuracy problem of result, is an implicit type cast
problem of argument.

exp2()'s argument is double and exp2f()'s is float.

As you know,
exp2(7.7) means exp2((double)7.7) and
exp2f(7.7) means exp2f((float)7.7).

(double)7.7 = 0x1.ecccdp+2 in %a format
= 7.7  in %.16g format
= 7.7002   in %.17g format.

(float)7.7  = 0x1.ecp+2 in %a format
= 7.7   in %.7g format
= 7.698 in %.8g format.

exp2((double)7.7)  = 0x1.9fdf8bcce533ep+7 = 207.9366 (%.7g) = 207.93661 (%.8g)
exp2((float)7.7)   = 0x1.9fdf883275843p+7 = 207.9366 (%.7g) = 207.93659 (%.8g)
exp2f((double)7.7) = 0x1.9fdf88p+7= 207.9366 (%.7g) = 207.93658 (%.8g)
exp2f((float)7.7)  = 0x1.9fdf88p+7= 207.9366 (%.7g) = 207.93658 (%.8g)

In the original code (t_exp.c,v 1.6), you execute exp2f(7.7) i.e.,
exp2f((float)7.7), but use 2^((double)7.7) as its expected value.
It's obviously wrong.
For exp2f((float)7.7) is 2^((float)7.7).

Please also see the following sample code.

By the way, in general:
Please write more details in comment at least if you're really
leaving such a failure intentionally, Or as a better way,
please send-pr it and use atf_tc_expect_fail(PR/x) feature.

Thank you.

-
% cat a.c
#include stdio.h
#include stdint.h
#include math.h

void print_float(const char *msg, float v)
{
printf(%s = %-20a = %.7g (%%.7g) = %.8g (%%.8g)\n, msg, v, v, v);
}

void print_double(const char *msg, double v)
{
printf(%s = %-20a = %.7g (%%.7g) = %.8g (%%.8g)\n, msg, v, v, v);
}

int main(int ac, char *av[])
{
float  f = 7.7;
double d = 7.7;
float f1;
float f2;

printf((double)7.7 = %-20a = %.16g (%%.16g) = %.17g (%%.17g)\n, d, d, d);
printf((float)7.7  = %-20a = %.7g (%%.7g)  = %.8g (%%.8g)\n, f, f, f);
printf(\n);

print_double(exp2((double)7.7) , exp2(d));
print_double(exp2((float)7.7)  , exp2(f));
print_float(exp2f((double)7.7), exp2f(d));
print_float(exp2f((float)7.7) , exp2f(f));
printf(\n);

f1 = exp2(d);
f2 = exp2f(f);
printf((float)exp2((double)7.7) = %.8g = 0x%08x\n, f1, *(uint32_t*)f1);
printf(   exp2f((float)7.7) = %.8g = 0x%08x\n, f2, *(uint32_t*)f2);
return 0;
}

% uname -srm
NetBSD 6.1.4_PATCH amd64
% gcc a.c -lm  ./a.out
(double)7.7 = 0x1.ecccdp+2 = 7.7 (%.16g) = 7.7002 (%.17g)
(float)7.7  = 0x1.ecp+2= 7.7 (%.7g)  = 7.698 (%.8g)

exp2((double)7.7)  = 0x1.9fdf8bcce533ep+7 = 207.9366 (%.7g) = 207.93661 (%.8g)
exp2((float)7.7)   = 0x1.9fdf883275843p+7 = 207.9366 (%.7g) = 207.93659 (%.8g)
exp2f((double)7.7) = 0x1.9fdf88p+7= 207.9366 (%.7g) = 207.93658 (%.8g)
exp2f((float)7.7)  = 0x1.9fdf88p+7= 207.9366 (%.7g) = 207.93658 (%.8g)

(float)exp2((double)7.7) = 207.93661 = 0x434fefc6
   exp2f((float)7.7) = 207.93658 = 0x434fefc4
%
-
---
Tetsuya Isaki is...@pastel-flower.jp / is...@netbsd.org


Re: CVS commit: src/tests/lib/libm

2014-10-15 Thread David Laight
On Tue, Oct 07, 2014 at 04:53:44PM +, Andreas Gustafsson wrote:
 Module Name:  src
 Committed By: gson
 Date: Tue Oct  7 16:53:44 UTC 2014
 
 Modified Files:
   src/tests/lib/libm: t_exp.c
 
 Log Message:
 In the exp2_values test case, provide separate expected return values
 for the float case, reflecting the actual exp2f() argument value after
 rounding to float precision.  Fixes PR lib/49256.  Thanks to Makoto
 Kamada and Tetsuya Isaki for the analysis.

The reason I left the tests failing is that the results should be more
accurate than the values that are actually returned.

Changing the 'expected' values so that the tests pass is just wrong.

What I should have got araound to doing is using the x87 instruction
to generate accurate 64bit mantissa (long double) results for the
values, and then looked at the sizes of the error terms.

I think the values ought to be accurate to one or two counts on the lsb
of the mantissa.

David

-- 
David Laight: da...@l8s.co.uk


Re: CVS commit: src/tests/lib/libm

2014-03-02 Thread Jukka Ruohonen
On Sat, Mar 01, 2014 at 09:08:39PM +, David Laight wrote:
 Log Message:
 Some of the acos() tests seem to fail on some systems.
 Sorting out why isn't helped by the tests not reporting the erronous value.
 Change the 'boilerplate' pattern used so that all the values are output.
 Reduce the amount of faffy red tape as well.
 Some of these reductions could be shared with other libm tests, but for
   the moment they are defined in this file.
 All these tests pass on my amd64 system, and when I run amd64 qemu.

This sounds like a good idea to remove boilerplate, i.e. a small-scale API
for all of the libm-tests. (Though the stuff behind the boilerplate is
justified as there has been so many bugs with these cornercase inf/NaN/etc.).

- Jukka.


Re: CVS commit: src/tests/lib/libm

2013-05-24 Thread Martin Husemann
On Thu, May 23, 2013 at 04:45:47PM -0400, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Thu May 23 20:45:47 UTC 2013
 
 Modified Files:
   src/tests/lib/libm: t_scalbn.c
 
 Log Message:
 vaxinate the new tests.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.8 -r1.9 src/tests/lib/libm/t_scalbn.c

This is wrong - unlike the other tests that use IEEE FP specific things,
the value tests should work on vax. I'll have a look and fix it properly.

Martin


Re: CVS commit: src/tests/lib/libm

2013-05-24 Thread Christos Zoulas
On May 24,  8:01am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libm

| This is wrong - unlike the other tests that use IEEE FP specific things,
| the value tests should work on vax. I'll have a look and fix it properly.

They could once you add scalbn to the vax libm. For now they don't link.

christos


Re: CVS commit: src/tests/lib/libm

2013-05-24 Thread Martin Husemann
On Fri, May 24, 2013 at 09:08:18AM -0400, Christos Zoulas wrote:
 On May 24,  8:01am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
 -- Subject: Re: CVS commit: src/tests/lib/libm
 
 | This is wrong - unlike the other tests that use IEEE FP specific things,
 | the value tests should work on vax. I'll have a look and fix it properly.
 
 They could once you add scalbn to the vax libm. For now they don't link.

Yes, exactly - your commit papered over a bug in the libm makefile
(it is a real mess), starting with a typo and a value later overwriten
by another assignment.

Matt, any chance to get POLYD functional, so this could all be cleaned up?

Martin


Re: CVS commit: src/tests/lib/libm

2013-05-24 Thread Matt Thomas

On May 24, 2013, at 6:44 AM, Martin Husemann mar...@duskware.de wrote:

 On Fri, May 24, 2013 at 09:08:18AM -0400, Christos Zoulas wrote:
 On May 24,  8:01am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
 -- Subject: Re: CVS commit: src/tests/lib/libm
 
 | This is wrong - unlike the other tests that use IEEE FP specific things,
 | the value tests should work on vax. I'll have a look and fix it properly.
 
 They could once you add scalbn to the vax libm. For now they don't link.
 
 Yes, exactly - your commit papered over a bug in the libm makefile
 (it is a real mess), starting with a typo and a value later overwriten
 by another assignment.
 
 Matt, any chance to get POLYD functional, so this could all be cleaned up?

vax asm.h has a polyd macro 



Re: CVS commit: src/tests/lib/libm

2011-09-16 Thread Martin Husemann
On Thu, Sep 15, 2011 at 11:05:51AM +, Havard Eidnes wrote:
 Module Name:  src
 Committed By: he
 Date: Thu Sep 15 11:05:51 UTC 2011
 
 Modified Files:
   src/tests/lib/libm: t_tan.c
 
 Log Message:
 #ifdef on __vax__ one more place, to avoid reference to tanf() for vax.

I am not sure if this is correct here. While some tests rely on NAN and
similar IEEE 754 specific properties of the underlying floating point
format should not be build (or skipped) on vax, this test case does not
have any reason not to build on vax (AFAICT).

At least this should be documented (PR, or src/doc/HACKS) and probably
tanf() for VAX added (should not be that hard).

Martin


Re: CVS commit: src/tests/lib/libm

2011-09-16 Thread Jukka Ruohonen
On Fri, Sep 16, 2011 at 09:02:37AM +, Martin Husemann wrote:
 I am not sure if this is correct here. While some tests rely on NAN and
 similar IEEE 754 specific properties of the underlying floating point
 format should not be build (or skipped) on vax, this test case does not
 have any reason not to build on vax (AFAICT).
 
 At least this should be documented (PR, or src/doc/HACKS) and probably
 tanf() for VAX added (should not be that hard).

Is there any consistent way to know which functions are available on VAX? 
Or even more generally, any consistent way to know which libm(3) functions
are available on which architectures?  (That is, there are ugly hacks like
#ifdef i386 || sparc || amd64 too.)

- Jukka.


Re: CVS commit: src/tests/lib/libm

2011-09-16 Thread Martin Husemann
On Fri, Sep 16, 2011 at 09:16:23PM +0300, Jukka Ruohonen wrote:
 Is there any consistent way to know which functions are available on VAX? 
 Or even more generally, any consistent way to know which libm(3) functions
 are available on which architectures?  (That is, there are ugly hacks like
 #ifdef i386 || sparc || amd64 too.)

Good question. I consider all those as hacks, they should be documented
and fixed, the soone the better.

Or, if there are hidden reasons, we should document them better and rename
the ifdefs to some __HAVE_... feature tests.

For VAX it is pretty easy: there is no NAN nor +/-INF (and IIRC zero is
zero, no +/- zero). Everything else is a bug somewhere and fixable.

Martin


Re: CVS commit: src/tests/lib/libm

2011-09-16 Thread David Laight
On Fri, Sep 16, 2011 at 08:41:47PM +0200, Martin Husemann wrote:
 On Fri, Sep 16, 2011 at 09:16:23PM +0300, Jukka Ruohonen wrote:
  Is there any consistent way to know which functions are available on VAX? 
  Or even more generally, any consistent way to know which libm(3) functions
  are available on which architectures?  (That is, there are ugly hacks like
  #ifdef i386 || sparc || amd64 too.)
 
 Good question. I consider all those as hacks, they should be documented
 and fixed, the soone the better.
 
 Or, if there are hidden reasons, we should document them better and rename
 the ifdefs to some __HAVE_... feature tests.
 
 For VAX it is pretty easy: there is no NAN nor +/-INF (and IIRC zero is
 zero, no +/- zero). Everything else is a bug somewhere and fixable.

The other things I can think of are:
- Denormalised values near zero (normally true)
- Strange byte orderings.

David

-- 
David Laight: da...@l8s.co.uk


Re: CVS commit: src/tests/lib/libm

2011-09-13 Thread Marc Balmer
Am 12.09.11 18:28, schrieb Jukka Ruohonen:
 Module Name:  src
 Committed By: jruoho
 Date: Mon Sep 12 16:28:37 UTC 2011
 
 Modified Files:
   src/tests/lib/libm: t_ldexp.c t_scalbn.c t_tanh.c
 
 Log Message:
 Happiness of VAX implies ugliness of the code.

But does it make the VAX really happy, if all the code is just ifdef'ed
out?  Or did I get that wrong that the tests are now simply disabled on
the vax?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libm/t_ldexp.c \
 src/tests/lib/libm/t_scalbn.c
 cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libm/t_tanh.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 
 
 
 
 Modified files:
 
 Index: src/tests/lib/libm/t_ldexp.c
 diff -u src/tests/lib/libm/t_ldexp.c:1.2 src/tests/lib/libm/t_ldexp.c:1.3
 --- src/tests/lib/libm/t_ldexp.c:1.2  Mon Sep 12 15:47:14 2011
 +++ src/tests/lib/libm/t_ldexp.c  Mon Sep 12 16:28:37 2011
 @@ -1,4 +1,4 @@
 -/* $NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
 +/* $NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $ */
  
  /*-
   * Copyright (c) 2011 The NetBSD Foundation, Inc.
 @@ -29,7 +29,7 @@
   * POSSIBILITY OF SUCH DAMAGE.
   */
  #include sys/cdefs.h
 -__RCSID($NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $);
 +__RCSID($NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $);
  
  #include math.h
  #include limits.h
 @@ -49,6 +49,7 @@
  
  ATF_TC_BODY(ldexp_nan, tc)
  {
 +#ifndef __vax__
   const double x = 0.0L / 0.0L;
   double y;
   size_t i;
 @@ -59,6 +60,7 @@
   y = ldexp(x, exps[i]);
   ATF_CHECK(isnan(y) != 0);
   }
 +#endif
  }
  
  ATF_TC(ldexp_inf_neg);
 @@ -69,11 +71,13 @@
  
  ATF_TC_BODY(ldexp_inf_neg, tc)
  {
 +#ifndef __vax__
   const double x = -1.0L / 0.0L;
   size_t i;
  
   for (i = 0; i  __arraycount(exps); i++)
   ATF_CHECK(ldexp(x, exps[i]) == x);
 +#endif
  }
  
  ATF_TC(ldexp_inf_pos);
 @@ -84,11 +88,13 @@
  
  ATF_TC_BODY(ldexp_inf_pos, tc)
  {
 +#ifndef __vax__
   const double x = 1.0L / 0.0L;
   size_t i;
  
   for (i = 0; i  __arraycount(exps); i++)
   ATF_CHECK(ldexp(x, exps[i]) == x);
 +#endif
  }
  
  ATF_TC(ldexp_zero_neg);
 @@ -99,6 +105,7 @@
  
  ATF_TC_BODY(ldexp_zero_neg, tc)
  {
 +#ifndef __vax__
   const double x = -0.0L;
   double y;
   size_t i;
 @@ -110,6 +117,7 @@
   ATF_CHECK(x == y);
   ATF_CHECK(signbit(y) != 0);
   }
 +#endif
  }
  
  ATF_TC(ldexp_zero_pos);
 @@ -120,6 +128,7 @@
  
  ATF_TC_BODY(ldexp_zero_pos, tc)
  {
 +#ifndef __vax__
   const double x = 0.0L;
   double y;
   size_t i;
 @@ -131,6 +140,7 @@
   ATF_CHECK(x == y);
   ATF_CHECK(signbit(y) == 0);
   }
 +#endif
  }
  
  ATF_TC(ldexpf_nan);
 @@ -141,6 +151,7 @@
  
  ATF_TC_BODY(ldexpf_nan, tc)
  {
 +#ifndef __vax__
   const float x = 0.0L / 0.0L;
   float y;
   size_t i;
 @@ -151,6 +162,7 @@
   y = ldexpf(x, exps[i]);
   ATF_CHECK(isnan(y) != 0);
   }
 +#endif
  }
  
  /*
 @@ -165,11 +177,13 @@
  
  ATF_TC_BODY(ldexpf_inf_neg, tc)
  {
 +#ifndef __vax__
   const float x = -1.0L / 0.0L;
   size_t i;
  
   for (i = 0; i  __arraycount(exps); i++)
   ATF_CHECK(ldexpf(x, exps[i]) == x);
 +#endif
  }
  
  ATF_TC(ldexpf_inf_pos);
 @@ -180,11 +194,13 @@
  
  ATF_TC_BODY(ldexpf_inf_pos, tc)
  {
 +#ifndef __vax__
   const float x = 1.0L / 0.0L;
   size_t i;
  
   for (i = 0; i  __arraycount(exps); i++)
   ATF_CHECK(ldexpf(x, exps[i]) == x);
 +#endif
  }
  
  ATF_TC(ldexpf_zero_neg);
 @@ -195,6 +211,7 @@
  
  ATF_TC_BODY(ldexpf_zero_neg, tc)
  {
 +#ifndef __vax__
   const float x = -0.0L;
   float y;
   size_t i;
 @@ -206,6 +223,7 @@
   ATF_CHECK(x == y);
   ATF_CHECK(signbit(y) != 0);
   }
 +#endif
  }
  
  ATF_TC(ldexpf_zero_pos);
 @@ -216,6 +234,7 @@
  
  ATF_TC_BODY(ldexpf_zero_pos, tc)
  {
 +#ifndef __vax__
   const float x = 0.0L;
   float y;
   size_t i;
 @@ -227,6 +246,7 @@
   ATF_CHECK(x == y);
   ATF_CHECK(signbit(y) == 0);
   }
 +#endif
  }
  
  ATF_TP_ADD_TCS(tp)
 Index: src/tests/lib/libm/t_scalbn.c
 diff -u src/tests/lib/libm/t_scalbn.c:1.2 src/tests/lib/libm/t_scalbn.c:1.3
 --- src/tests/lib/libm/t_scalbn.c:1.2 Mon Sep 12 15:47:14 2011
 +++ src/tests/lib/libm/t_scalbn.c Mon Sep 12 16:28:37 2011
 @@ -1,4 +1,4 @@
 -/* $NetBSD: t_scalbn.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
 +/* $NetBSD: t_scalbn.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $ */
  
  /*-
   * Copyright (c) 2011 The NetBSD Foundation, Inc.
 @@ -29,7 +29,7 @@
   * POSSIBILITY OF SUCH DAMAGE.
   */
  #include sys/cdefs.h
 -__RCSID($NetBSD: t_scalbn.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $);
 +__RCSID($NetBSD: t_scalbn.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $);
  
  #include 

Re: CVS commit: src/tests/lib/libm

2011-09-13 Thread Jukka Ruohonen
On Tue, Sep 13, 2011 at 08:38:07AM +0200, Marc Balmer wrote:
 Am 12.09.11 18:28, schrieb Jukka Ruohonen:
  Module Name:src
  Committed By:   jruoho
  Date:   Mon Sep 12 16:28:37 UTC 2011
  
  Modified Files:
  src/tests/lib/libm: t_ldexp.c t_scalbn.c t_tanh.c
  
  Log Message:
  Happiness of VAX implies ugliness of the code.
 
 But does it make the VAX really happy, if all the code is just ifdef'ed
 out?  Or did I get that wrong that the tests are now simply disabled on
 the vax?

You are right. I didn't bother to do atf_tc_skip() for the special case of
VAX. If any of the VAX people want to run the tests, please feel free to fix.

- Jukka.

 
  
  
  To generate a diff of this commit:
  cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libm/t_ldexp.c \
  src/tests/lib/libm/t_scalbn.c
  cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libm/t_tanh.c
  
  Please note that diffs are not public domain; they are subject to the
  copyright notices on the relevant files.
  
  
  
  
  Modified files:
  
  Index: src/tests/lib/libm/t_ldexp.c
  diff -u src/tests/lib/libm/t_ldexp.c:1.2 src/tests/lib/libm/t_ldexp.c:1.3
  --- src/tests/lib/libm/t_ldexp.c:1.2Mon Sep 12 15:47:14 2011
  +++ src/tests/lib/libm/t_ldexp.cMon Sep 12 16:28:37 2011
  @@ -1,4 +1,4 @@
  -/* $NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
  +/* $NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $ */
   
   /*-
* Copyright (c) 2011 The NetBSD Foundation, Inc.
  @@ -29,7 +29,7 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
   #include sys/cdefs.h
  -__RCSID($NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $);
  +__RCSID($NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $);
   
   #include math.h
   #include limits.h
  @@ -49,6 +49,7 @@
   
   ATF_TC_BODY(ldexp_nan, tc)
   {
  +#ifndef __vax__
  const double x = 0.0L / 0.0L;
  double y;
  size_t i;
  @@ -59,6 +60,7 @@
  y = ldexp(x, exps[i]);
  ATF_CHECK(isnan(y) != 0);
  }
  +#endif
   }
   
   ATF_TC(ldexp_inf_neg);
  @@ -69,11 +71,13 @@
   
   ATF_TC_BODY(ldexp_inf_neg, tc)
   {
  +#ifndef __vax__
  const double x = -1.0L / 0.0L;
  size_t i;
   
  for (i = 0; i  __arraycount(exps); i++)
  ATF_CHECK(ldexp(x, exps[i]) == x);
  +#endif
   }
   
   ATF_TC(ldexp_inf_pos);
  @@ -84,11 +88,13 @@
   
   ATF_TC_BODY(ldexp_inf_pos, tc)
   {
  +#ifndef __vax__
  const double x = 1.0L / 0.0L;
  size_t i;
   
  for (i = 0; i  __arraycount(exps); i++)
  ATF_CHECK(ldexp(x, exps[i]) == x);
  +#endif
   }
   
   ATF_TC(ldexp_zero_neg);
  @@ -99,6 +105,7 @@
   
   ATF_TC_BODY(ldexp_zero_neg, tc)
   {
  +#ifndef __vax__
  const double x = -0.0L;
  double y;
  size_t i;
  @@ -110,6 +117,7 @@
  ATF_CHECK(x == y);
  ATF_CHECK(signbit(y) != 0);
  }
  +#endif
   }
   
   ATF_TC(ldexp_zero_pos);
  @@ -120,6 +128,7 @@
   
   ATF_TC_BODY(ldexp_zero_pos, tc)
   {
  +#ifndef __vax__
  const double x = 0.0L;
  double y;
  size_t i;
  @@ -131,6 +140,7 @@
  ATF_CHECK(x == y);
  ATF_CHECK(signbit(y) == 0);
  }
  +#endif
   }
   
   ATF_TC(ldexpf_nan);
  @@ -141,6 +151,7 @@
   
   ATF_TC_BODY(ldexpf_nan, tc)
   {
  +#ifndef __vax__
  const float x = 0.0L / 0.0L;
  float y;
  size_t i;
  @@ -151,6 +162,7 @@
  y = ldexpf(x, exps[i]);
  ATF_CHECK(isnan(y) != 0);
  }
  +#endif
   }
   
   /*
  @@ -165,11 +177,13 @@
   
   ATF_TC_BODY(ldexpf_inf_neg, tc)
   {
  +#ifndef __vax__
  const float x = -1.0L / 0.0L;
  size_t i;
   
  for (i = 0; i  __arraycount(exps); i++)
  ATF_CHECK(ldexpf(x, exps[i]) == x);
  +#endif
   }
   
   ATF_TC(ldexpf_inf_pos);
  @@ -180,11 +194,13 @@
   
   ATF_TC_BODY(ldexpf_inf_pos, tc)
   {
  +#ifndef __vax__
  const float x = 1.0L / 0.0L;
  size_t i;
   
  for (i = 0; i  __arraycount(exps); i++)
  ATF_CHECK(ldexpf(x, exps[i]) == x);
  +#endif
   }
   
   ATF_TC(ldexpf_zero_neg);
  @@ -195,6 +211,7 @@
   
   ATF_TC_BODY(ldexpf_zero_neg, tc)
   {
  +#ifndef __vax__
  const float x = -0.0L;
  float y;
  size_t i;
  @@ -206,6 +223,7 @@
  ATF_CHECK(x == y);
  ATF_CHECK(signbit(y) != 0);
  }
  +#endif
   }
   
   ATF_TC(ldexpf_zero_pos);
  @@ -216,6 +234,7 @@
   
   ATF_TC_BODY(ldexpf_zero_pos, tc)
   {
  +#ifndef __vax__
  const float x = 0.0L;
  float y;
  size_t i;
  @@ -227,6 +246,7 @@
  ATF_CHECK(x == y);
  ATF_CHECK(signbit(y) == 0);
  }
  +#endif
   }
   
   ATF_TP_ADD_TCS(tp)
  Index: src/tests/lib/libm/t_scalbn.c
  diff -u src/tests/lib/libm/t_scalbn.c:1.2 src/tests/lib/libm/t_scalbn.c:1.3
  --- src/tests/lib/libm/t_scalbn.c:1.2   Mon Sep 12 15:47:14 2011
  +++ src/tests/lib/libm/t_scalbn.c   Mon Sep 12 16:28:37 2011
  @@ -1,4 +1,4 @@
  -/* $NetBSD: t_scalbn.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
  +/* $NetBSD: 

Re: CVS commit: src/tests/lib/libm

2011-09-13 Thread Jukka Ruohonen
On Tue, Sep 13, 2011 at 06:50:41AM +, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Tue Sep 13 06:50:41 UTC 2011
 
 Modified Files:
   src/tests/lib/libm: t_scalbn.c
 
 Log Message:
 Test that scalbn(x) == ldexp(2) whenever FLT_RADIX == 2 (like it should be
 on all systems except exotic relics such as IBM 360).

Ehm. scalbn(x) == ldexp(x) obviously.

- Jukka.


Re: CVS commit: src/tests/lib/libm

2011-09-13 Thread Martin Husemann
On Tue, Sep 13, 2011 at 09:48:37AM +0300, Jukka Ruohonen wrote:
 You are right. I didn't bother to do atf_tc_skip() for the special case of
 VAX. If any of the VAX people want to run the tests, please feel free to fix.

Unfortunately this would require (definitively non trivial) gcc fixes first.

Martin


Re: CVS commit: src/tests/lib/libm

2011-09-12 Thread Christos Zoulas
In article 20110912162837.5501917...@cvs.netbsd.org,
Jukka Ruohonen source-changes-d@NetBSD.org wrote:
-=-=-=-=-=-

Module Name:   src
Committed By:  jruoho
Date:  Mon Sep 12 16:28:37 UTC 2011

Modified Files:
   src/tests/lib/libm: t_ldexp.c t_scalbn.c t_tanh.c

Log Message:
Happiness of VAX implies ugliness of the code.


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libm/t_ldexp.c \
src/tests/lib/libm/t_scalbn.c
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libm/t_tanh.c

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

We should probably grow a __HAVE_IEEE754FP

christos