NetBSD Problem Report #44057

From www@NetBSD.org  Sun Nov  7 14:27:01 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id C18E263BAC6
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  7 Nov 2010 14:27:00 +0000 (UTC)
Message-Id: <20101107142700.5630363BABA@www.NetBSD.org>
Date: Sun,  7 Nov 2010 14:27:00 +0000 (UTC)
From: victor.stinner@haypocalc.com
Reply-To: victor.stinner@haypocalc.com
To: gnats-bugs@NetBSD.org
Subject: tanh() function doesn't preserve the zero sign
X-Send-Pr-Version: www-1.0

>Number:         44057
>Category:       lib
>Synopsis:       tanh() function doesn't preserve the zero sign
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 07 14:30:00 +0000 2010
>Closed-Date:    Sat Dec 19 02:40:07 +0000 2015
>Last-Modified:  Sat Dec 19 02:40:07 +0000 2015
>Originator:     Victor Stinner
>Release:        5.0.x
>Organization:
>Environment:
"NetBSD 5.0.x i386", sorry I don't know more. It's a Python buildbot at:
http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/

>Description:
Python test suite (test_math and test_cmath) fails on a test of the tanh() result sign for float and complex numbers. Python configure script has a test to check if tanh() preserves the sign or not: I just commited a patch to skip these tests if tanh() doesn't preserve the sign.

Python (closed) bug: http://bugs.python.org/issue10337
Commit: http://svn.python.org/view?rev=86299&view=rev

Extract of Python configure test:

# On FreeBSD 6.2, it appears that tanh(-0.) returns 0. instead of
# -0. on some architectures.
AC_MSG_CHECKING(whether tanh preserves the sign of zero)
AC_CACHE_VAL(ac_cv_tanh_preserves_zero_sign, [
AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <math.h>
#include <stdlib.h>
int main() {
    /* return 0 if either negative zeros don't exist
       on this platform or if negative zeros exist
       and tanh(-0.) == -0. */
  if (atan2(0., -1.) == atan2(-0., -1.) ||
      atan2(tanh(-0.), -1.) == atan2(-0., -1.)) exit(0);
  else exit(1);
}
]])],
[ac_cv_tanh_preserves_zero_sign=yes],
[ac_cv_tanh_preserves_zero_sign=no],
[ac_cv_tanh_preserves_zero_sign=no])])
AC_MSG_RESULT($ac_cv_tanh_preserves_zero_sign)
if test "$ac_cv_tanh_preserves_zero_sign" = yes
then
  AC_DEFINE(TANH_PRESERVES_ZERO_SIGN, 1,
  [Define if tanh(-0.) is -0., or if platform doesn't have signed zeros])
fi

So it looks like FreeBSD 6.2 has the same bug.
>How-To-Repeat:
Expected output:

$ python -c "import math; print(math.tanh(-0.0))"
-0.0
>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Wed, 06 Apr 2011 09:29:11 +0000
State-Changed-Why:

I can not reproduce this in 5.99.48 amd64 NetBSD. But the bug is present on
5.1 i386 NetBSD. Can you check if the problem is exists in HEAD i386? 



From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44057 CVS commit: src
Date: Wed, 6 Apr 2011 09:35:49 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Wed Apr  6 09:35:49 UTC 2011

 Modified Files:
 	src/distrib/sets/lists/tests: mi
 	src/tests/lib/libm: Makefile
 Added Files:
 	src/tests/lib/libm: t_tanh.c

 Log Message:
 A test case for PR lib/44057.


 To generate a diff of this commit:
 cvs rdiff -u -r1.295 -r1.296 src/distrib/sets/lists/tests/mi
 cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libm/Makefile
 cvs rdiff -u -r0 -r1.1 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.

From: Victor Stinner <victor.stinner@haypocalc.com>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
 gnats-admin@netbsd.org,  jruoho@NetBSD.org
Subject: Re: lib/44057 (tanh() function doesn't preserve the zero sign)
Date: Wed, 06 Apr 2011 11:41:48 +0200

 Le mercredi 06 avril 2011 à 09:29 +0000, jruoho@NetBSD.org a écrit :
 > Synopsis: tanh() function doesn't preserve the zero sign
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: jruoho@NetBSD.org
 > State-Changed-When: Wed, 06 Apr 2011 09:29:11 +0000
 > State-Changed-Why:
 > 
 > I can not reproduce this in 5.99.48 amd64 NetBSD. But the bug is present on
 > 5.1 i386 NetBSD. Can you check if the problem is exists in HEAD i386? 

 Sorry, I cannot. I don't have access to any NetBSD machine.

 tanh(-0.) should return -0.

 You may try python -c "import math; print(math.tanh(-0.0))" or a program
 written in C.

 Victor

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, victor.stinner@haypocalc.com
Subject: Re: lib/44057 (tanh() function doesn't preserve the zero sign)
Date: Wed, 6 Apr 2011 11:55:28 +0200

 I tested on i386/5.1 and it fails there on i386 (basically the test case
 t_tanh you just added to -current):

    signbit(d): 0 signbit(f): 1, d = 0.000000, f = -0.000000

 So works for float, fails for double. Also fails on sparc64 current :-(

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/44057 (tanh() function doesn't preserve the zero sign)
Date: Wed, 6 Apr 2011 12:12:33 +0200

 Does also fail (differntly) on alpha (running -current).
 Works on shark (current).

 Martin

State-Changed-From-To: feedback->open
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Wed, 06 Apr 2011 18:38:06 +0000
State-Changed-Why:

The problem is still present. It is also verified to exist on several
different architectures.



From: Taylor R Campbell <campbell+netbsd@mumble.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/44057
Date: Fri, 15 Apr 2011 17:04:10 +0000

 The problem is that GCC has distributed x*(one + x) = x + (x*x) in the
 definition of tanh in src/lib/libm/src/s_tanh.c, as revealed by
 disassembling libm.so.

 I suspect that GCC fixed this in SVN revision 152443 by adding the
 following fragment to the top of distribute_and_simplify_rtx in
 gcc/combine.c:

   if (FLOAT_MODE_P (GET_MODE (x))
       && ! flag_unsafe_math_optimizations)
     return NULL_RTX;

 I don't have the resources to test this hypothesis right now, though.
 I imagine that if this fixes the problem, it is safe to back-port to
 whatever version of GCC we are using; the surrounding code looks
 pretty similar.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/44057
Date: Sat, 16 Apr 2011 20:27:26 +0200

 --h31gzZEtNLTqOjlF
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 Following this suggestion I tested the attached patch, and it made both
 sparc64 and alpha pass the test.

 I am not going to commit this to keep clear out of license problems.
 Now that we know it is a gcc bug, let the problem rest untill a newer
 gcc gets imported.

 If this should not happen before the branch for NetBSD 6, let core/board
 decide how to deal with it.

 Martin

 --h31gzZEtNLTqOjlF
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="combine.c.patch"

 Index: combine.c
 ===================================================================
 RCS file: /cvsroot/src/gnu/dist/gcc4/gcc/combine.c,v
 retrieving revision 1.1.1.5
 diff -c -u -p -r1.1.1.5 combine.c
 --- combine.c	31 Aug 2008 09:31:22 -0000	1.1.1.5
 +++ combine.c	16 Apr 2011 18:20:32 -0000
 @@ -8257,6 +8257,9 @@ distribute_and_simplify_rtx (rtx x, int 
      return NULL_RTX;

    mode = GET_MODE (x);
 +  if (FLOAT_MODE_P (mode) && !flag_unsafe_math_optimizations)
 +    return NULL_RTX;
 +
    outer_code = GET_CODE (x);
    distributed = XEXP (x, !n);


 --h31gzZEtNLTqOjlF--

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44057 CVS commit: src/tests/lib/libm
Date: Tue, 26 Apr 2011 20:20:17 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Tue Apr 26 20:20:16 UTC 2011

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

 Log Message:
 When failing, point to PR lib/44057 and the discussion therein about the
 relevant compiler bug.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 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.

State-Changed-From-To: open->suspended
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 30 Apr 2011 05:03:36 +0000
State-Changed-Why:
needs either a cleanroom fix or a gplv3 gcc import...

(shouldn't it be possible to work around the problem by adding goop to
the relevant libm code?)


State-Changed-From-To: suspended->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 19 Dec 2015 02:40:07 +0000
State-Changed-Why:
only affected < 6.0 and those are now EOL


>Unformatted:

Home	PR Database Search