[Bug math/887] New: Math library function "logb" and "nextafter" inconsistent

[Bug math/887] New: Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

Math library function logb give different result for some input values when 
   rounding mode "towards -ve infinity" is set and not set. Values for which I 
   got miscompare are "0X3FF0000000000000", "0X3FF8000000000000", 
   "0X3FF2000000000000", "0X3FFFFFFFFFFFFFFF", "0X3FF7FFFFFFFFFFFF" and 
   "0X3FF1FFFFFFFFFFFF".

Values obtained when rounding mode "towards -ve infinity" for all above input 
values-
                    "0x8000000000000000"
Values obtained when no rounding mode is set for all above input values-
                     "0x0000000000000000"


Similar problem i have seen with function nextafter - when rounding mode is set
it gives some value and when it is not set gives some value.

-- 
           Summary: Math library function "logb" and "nextafter"
                    inconsistent
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
        AssignedTo: uttamp at us dot ibm dot com
        ReportedBy: uttamp at us dot ibm dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: PowerPC (ppc64)
  GCC host triplet: PowerPC (ppc64)
GCC target triplet: PowerPC (ppc64)


http://sources.redhat.com/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-04-29 20:38 -------
Created an attachment (id=470)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=470&action=view)
A propsed patch to fix bug in logb() function on powerpc arch.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-06-16 19:12 -------
The patch has been tested for the above platform and did complete clean build.
Did not see any new failures.I'm changing the status from NEW to FIXED. Can it
be verifed and checked in, please?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-07-19 22:16 -------
Created an attachment (id=559)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=559&action=view)
proposed patch for nextafter() for powerpc

A proposed fix for a bug in nextafter() librray function.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-10-25 17:05 -------
Ping. Can anybody verify this patch, please? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at gnu dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-11-02 01:29 -------
This patch has not been accepted in the mainline yet. And I would like
maintainer to look at the patch as It has been tested with no new failure and
like to reopen this bug till this patch gets accepted.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[uttamp at us dot ibm dot com]

------- Additional Comments From uttamp at us dot ibm dot com  2005-11-21 17:57 -------
Ping.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2005-11-21 18:07 -------
The patch is definitely wrong.
First of all, you haven't proven in any way with standard references that
the current behaviour is incorrect.
If that is a bug (I'm not aware of any part of the standard that would mandate
that), then it would be a generic GCC problem on ppc32 with casts from int
to double with FE_DOWNWARD rounding.  As on ppc32 we can't assume a hw
instruction for that, GCC on ppc32 computes the cast as
((double) (4503601774854144 + i)) - 4503601774854144.0
for int i.  With FE_DOWNWARD rounding and i == 0, this results in -0.0.
Working around this for two randomly picked functions when the same thing
occurs in hundreds of other functions is certainly not the way to go.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm dot com]

------- Additional Comments From rsa at us dot ibm dot com  2006-09-30 05:02 -------
Created an attachment (id=1339)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1339&action=view)
logb test case demonstrating the described behavior

The included test case demonstrates the described behavior.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|uttamp at us dot ibm dot com|rsa at us dot ibm dot com
             Status|REOPENED                    |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm dot com]

------- Additional Comments From rsa at us dot ibm dot com  2006-09-30 05:54 -------
The behavior following fesetround(FE_DOWNWARD) is exhibited on the fsub
operation where f0 and f13 are the same both times fsub is called (before and
after the rounding mode is set):

10000390:       fc 0d 00 28     fsub    f0,f13,f0

The bug doesn't have anything to do with GCC.  The rounding mode is set in the
fpu's FPSCR using the fesetround() function and is applied to the fsub operation.

According to the PowerPC architecture specification for the fsub operation "The
result is rounded to the target precision under control of the Floating-Point
Rounding Control field RN of the FPSCR and placed into register FRT."

Indeed, when the -0.0 result is encountered from fsub following
fesetround(FE_DOWNWARD) the fpscr's rounding mode bits are set for '11' "Round
toward - Infinity":

fpscr          0x4003   16387

And when the 0.0 result is encountered from fsub prior to
fesetround(FE_DOWNWARD) the fpscr's rounding mode bits are set to '00' "Round to
Nearest"

fpscr          0x4000   16384

At worst we're simply encountering the processor defined behavior for fsub.

I reviewed the C99 spec and IEEE754r and could find no mention of logb behavior
regarding rounding mode.  It simply appears to be undefined.

The implementation of logb() makes use of fsub and an identical result is
encountered there.

This same behavior was exhibited on i386.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=887

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #10 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-22 21:43:55 UTC ---
Regarding logb and the sign of zero, IEEE 754-2008 says (section 5.3.3) that
"logB(1) is +0.".  I think that's a clear indication that glibc should not
return -0 from logb in any rounding mode.

Regarding nextafter, although there is a patch claiming to fix some problem I
see no statement of what the problem is (i.e. this is not a complete bug report
- and anyway a report for nextafter would best be a separate bug report). 
Anyway, 754-2008 doesn't appear to define nextafter, but it has nextUp and
nextDown.  Their results do not depend on rounding mode, so it appears that if
the two arguments to nextafter compare unequal and neither is NaN, then if the
result is zero it must have the sign of x independent of rounding mode.

Regarding conversion from integers to floating point, "Integer zeros without
signs are converted to +0." (754-2008, section 5.4.1).  So I think it is wrong
to convert them to -0 in round-downwards mode.  Of course this is only a GCC
bug if -frounding-math is used; otherwise GCC is entitled to assume
round-to-nearest.  If -frounding-math, I think GCC for 32-bit Power
Architecture needs to save and restore the rounding mode when doing these
conversions.

Then it would be possible to compile the logb code with -frounding-math.  There
would still be the question of any architecture-specific workaround for older
GCC, since a testcase for logb in different rounding modes ought to go in the
testsuite but you might not want older GCC to make the testsuite fail.

Ryan, are you actually still working on this?  If not, please unassign
yourself.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #11 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-23 19:48:48 UTC ---
Here's an actual testcase which demonstrates the behavior in logb that's
undesireable:


#include <stdio.h>
#include <math.h>
#include <fenv.h>
#include <float.h>

#define NUM_INPUTS 6
int main() {

  double ret;
  int i = 0;

  typedef union {
    long long ll;
    double   d;
  } input;

  input inputs[NUM_INPUTS];

  inputs[0].ll = 0X3FF0000000000000LL;
  inputs[1].ll = 0X3FF8000000000000LL;
  inputs[2].ll = 0X3FF2000000000000LL;
  inputs[3].ll = 0X3FFFFFFFFFFFFFFFLL;
  inputs[4].ll = 0X3FF7FFFFFFFFFFFFLL;
  inputs[5].ll = 0X3FF1FFFFFFFFFFFFLL;

  for (i=0;i<NUM_INPUTS;i++)
    {
      printf ("Input: %f\n",inputs[i].d);

      fesetround (FE_TONEAREST);
      ret = logb (inputs[i].d);
      printf ("%f\n",ret);

      fesetround (FE_DOWNWARD);
      ret = logb (inputs[i].d);
      printf ("%f\n",ret);
    }

  return 0;
}

This doesn't fail on PowerPC64:

~/bugs/GLIBC887/$ vim foo.c 
~/bugs/GLIBC887/$ gcc -m64 foo.c -o foo -lm
~/bugs/GLIBC887/$ ./foo 
Input: 1.000000
0.000000
0.000000
Input: 1.500000
0.000000
0.000000
Input: 1.125000
0.000000
0.000000
Input: 2.000000
0.000000
0.000000
Input: 1.500000
0.000000
0.000000
Input: 1.125000
0.000000
0.000000

gcc version 4.1.2 20070115 (SUSE Linux)

But it does fail with 32-bit PowerPC:

~/bugs/GLIBC887/$ gcc -m32 foo.c -o foo -lm
~/bugs/GLIBC887/$ ./foo 
Input: 1.000000
0.000000
-0.000000
Input: 1.500000
0.000000
-0.000000
Input: 1.125000
0.000000
-0.000000
Input: 2.000000
0.000000
-0.000000
Input: 1.500000
0.000000
-0.000000
Input: 1.125000
0.000000
-0.000000

gcc version 4.1.2 20070115 (SUSE Linux)
libc-2.4.so

I tried a newer compiler and library:

~/bugs/GLIBC887/$ /opt/at4.0/bin/gcc -m32 foo.c -o foo -lm
~/bugs/GLIBC887/$ ./foo
Input: 1.000000
0.000000
0.000000
Input: 1.500000
0.000000
0.000000
Input: 1.125000
0.000000
0.000000
Input: 2.000000
0.000000
0.000000
Input: 1.500000
0.000000
0.000000
Input: 1.125000
0.000000
0.000000

gcc version 4.5.4 20110524 (Advance-Toolchain-4.0-5) [ibm/gcc-4_5-branch
revision 179810] (GCC)
libc-2.12.1.so

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #12 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-23 21:28:45 UTC ---
Here's a testcase for nextafter:


#include <stdio.h>
#include <math.h>
#include <fenv.h>
#include <float.h>

#define NUM_INPUTS 3
#define NUM_TOWARDS 2
int main() {

  int i = 0;
  int j = 0;

  typedef union {
    long long ll;
    double   d;
  } input;

  input ret;

  input inputs[NUM_INPUTS] =
  {
    [0].ll = 0x3000000000000001LL,
    [1].ll = 0x0000000000000001LL,
    [2].ll = 0x0000000000000000LL,
  };

  double toward[NUM_TOWARDS] =
  {
    -__DBL_MAX__,
    __DBL_MAX__
  };

  for (j=0;j<NUM_TOWARDS;j++)
    {
      for (i=0;i<NUM_INPUTS;i++)
        {
          printf ("Input:  %.*e\n    [0x%0.16llx]\n",
                          __DBL_MANT_DIG__,
                          inputs[i].d,
                          inputs[i].ll);
          printf ("Toward: %.*e\n",__DBL_MANT_DIG__,toward[j]);

          fesetround (FE_TONEAREST);
          ret.d = nextafter(inputs[i].d,toward[j]);
          printf ("%.*e\n    [0x%0.16llx]\n",
                          __DBL_MANT_DIG__,
                          ret.d,ret.ll);

          fesetround (FE_DOWNWARD);
          ret.d = nextafter(inputs[i].d,toward[j]);
          printf ("%.*e\n    [0x%0.16llx]\n\n",
                          __DBL_MANT_DIG__,
                          ret.d,
                          ret.ll);
        }
    }

    return 0;
}

Using gcc version 4.1.2 20070115 (SUSE Linux)

The result is:


Input:  1.72723371101888930860019734894496687483038405619004088e-77
    [0x3000000000000001]
Toward: -1.79769313486231570814527423731704356798070567525844997e+308
1.72723371101888892507727037256007991422320007288725628e-77
    [0x3000000000000000]
1.72723371101888892507727037256007991422320007288725628e-77
    [0x3000000000000000]

Input:  4.94065645841246544176568792868221372365059802614324764e-324
    [0x0000000000000001]
Toward: -1.79769313486231570814527423731704356798070567525844997e+308
0.00000000000000000000000000000000000000000000000000000e+00
    [0x0000000000000000]
0.00000000000000000000000000000000000000000000000000000e+00
    [0x0000000000000000]

Input:  0.00000000000000000000000000000000000000000000000000000e+00
    [0x0000000000000000]
Toward: -1.79769313486231570814527423731704356798070567525844997e+308
-4.94065645841246544176568792868221372365059802614324764e-324
    [0x8000000000000001]
-4.94065645841246544176568792868221372365059802614324764e-324
    [0x8000000000000001]

Input:  1.72723371101888930860019734894496687483038405619004088e-77
    [0x3000000000000001]
Toward: 1.79769313486231570814527423731704356798070567525844997e+308
1.72723371101888969212312432532985383543756803949282549e-77
    [0x3000000000000002]
1.72723371101888969212312432532985383543756803949282549e-77
    [0x3000000000000002]

Input:  4.94065645841246544176568792868221372365059802614324764e-324
    [0x0000000000000001]
Toward: 1.79769313486231570814527423731704356798070567525844997e+308
9.88131291682493088353137585736442744730119605228649529e-324
    [0x0000000000000002]
9.88131291682493088353137585736442744730119605228649529e-324
    [0x0000000000000002]

Input:  0.00000000000000000000000000000000000000000000000000000e+00
    [0x0000000000000000]
Toward: 1.79769313486231570814527423731704356798070567525844997e+308
4.94065645841246544176568792868221372365059802614324764e-324
    [0x0000000000000001]
4.94065645841246544176568792868221372365059802614324764e-324
    [0x0000000000000001]

So I'm not seeing this reproduce for nextafter.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-23 21:39:33 UTC ---
If you're not seeing this with current compilers and glibc I guess that 
means we should add testcases to libm-test.inc (in the style of the 
existing tests for functions in particular rounding modes), verify that 
they do pass and close this bug as fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #14 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-23 21:44:29 UTC ---
(In reply to comment #13)
> If you're not seeing this with current compilers and glibc I guess that 
> means we should add testcases to libm-test.inc (in the style of the 
> existing tests for functions in particular rounding modes), verify that 
> they do pass and close this bug as fixed.

Sure I'm fine with that.  I'll work these into testcases and do that.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

Ryan S. Arnold <rsa at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.16

--- Comment #15 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-23 23:17:36 UTC ---
(In reply to comment #13)
> If you're not seeing this with current compilers and glibc I guess that 
> means we should add testcases to libm-test.inc (in the style of the 
> existing tests for functions in particular rounding modes), verify that 
> they do pass and close this bug as fixed.

I'm not sure if there's any point in doing a testcase for nextafter if I can't
reproduce it in the first place.  I'll try to find a system with an older GCC
to reproduce on.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #16 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-29 16:22:12 UTC ---
I attempted to reproduce the alleged nextafter errors on an old distro with the
following package versions:

GLIBC 2.3.5
gcc version 3.3.3

And was unable to do so.  I'm not sure it's worth including the nextafter
testcase or not.

I'll post the patch shortly.

--- Comment #17 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-29 16:22:12 UTC ---
I attempted to reproduce the alleged nextafter errors on an old distro with the
following package versions:

GLIBC 2.3.5
gcc version 3.3.3

And was unable to do so.  I'm not sure it's worth including the nextafter
testcase or not.

I'll post the patch shortly.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #16 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-29 16:22:12 UTC ---
I attempted to reproduce the alleged nextafter errors on an old distro with the
following package versions:

GLIBC 2.3.5
gcc version 3.3.3

And was unable to do so.  I'm not sure it's worth including the nextafter
testcase or not.

I'll post the patch shortly.

--- Comment #17 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-02-29 16:22:12 UTC ---
I attempted to reproduce the alleged nextafter errors on an old distro with the
following package versions:

GLIBC 2.3.5
gcc version 3.3.3

And was unable to do so.  I'm not sure it's worth including the nextafter
testcase or not.

I'll post the patch shortly.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #18 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-01 21:26:05 UTC ---
A bit more investigation reveals the issue:

Building logb with -mcpu=power4 or -mcpu=ppc970 results in a negative signed
zero.  This is due to the power4 and ppc970 versions using fsub.

The fcfid insn was introduced after power4 and logb uses that when built for
power5 and power6.  A negative signed zero is not encountered in these cases.

So technically YES, this is still an issue, but it originates in GCC due to
insn selection.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #19 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-26 17:43:26 UTC ---
Testing the following as a preliminary patch:

diff --git a/math/libm-test.inc b/math/libm-test.inc
index 3851855..ea50e63 100644
--- a/math/libm-test.inc
+++ b/math/libm-test.inc
@@ -5000,6 +5000,39 @@ logb_test (void)
   END (logb);
 }

+static void
+logb_test_downward (void)
+{
+  int save_round_mode;
+  errno = 0;
+
+  FUNC(logb) (0);
+  if (errno == ENOSYS)
+    /* Function not implemented.  */
+    return;
+
+  START (logb_downward);
+
+  save_round_mode = fegetround ();
+
+  if (!fesetround (FE_DOWNWARD))
+    {
+
+      /* IEEE 754-2008 says (section 5.3.3) that "logB(1) is +0.".  Libm
+       * should not return -0 from logb in any rounding mode.  PowerPC32 is
+       * known to fail with this test for power4 and earlier hardware due
+       * the instructions available for the logb computation at the POWER4
+       * and earlier ISA level.  POWER4 uses an fsub in the calculation which
+       * propogates a negative sign in a downward rounding mode.  */
+
+      /* BZ #887 .*/
+      TEST_f_f (logb, 1.000e+0, plus_zero);
+    }
+
+  fesetround (save_round_mode);
+
+  END (logb_downward);
+}

 static void
 lround_test (void)
@@ -7834,6 +7867,7 @@ main (int argc, char **argv)
   log1p_test ();
   log2_test ();
   logb_test ();
+  logb_test_downward ();
   modf_test ();
   ilogb_test ();
   scalb_test ();

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #20 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-26 20:09:40 UTC ---
Here's a more thorough patch which includes -frounding-math when building
s_logb.c and only tests on 'double'.

diff --git a/math/libm-test.inc b/math/libm-test.inc
index 3851855..df83a45 100644
--- a/math/libm-test.inc
+++ b/math/libm-test.inc
@@ -5000,6 +5000,41 @@ logb_test (void)
   END (logb);
 }

+static void
+logb_test_downward (void)
+{
+  int save_round_mode;
+  errno = 0;
+
+  FUNC(logb) (0);
+  if (errno == ENOSYS)
+    /* Function not implemented.  */
+    return;
+
+  START (logb_downward);
+
+  save_round_mode = fegetround ();
+
+  if (!fesetround (FE_DOWNWARD))
+    {
+
+      /* IEEE 754-2008 says (section 5.3.3) that "logB(1) is +0.".  Libm
+       * should not return -0 from logb in any rounding mode.  PowerPC32 is
+       * known to fail with this test for power4 and earlier hardware due
+       * the instructions available for the logb computation at the POWER4
+       * and earlier ISA level.  POWER4 uses an fsub in the calculation which
+       * propogates a negative sign in a downward rounding mode.  */
+
+#if defined TEST_DOUBLE
+      /* BZ #887 .*/
+      TEST_f_f (logb, 1.000e+0, plus_zero);
+#endif /* TEST_DOUBLE  */
+    }
+
+  fesetround (save_round_mode);
+
+  END (logb_downward);
+}

 static void
 lround_test (void)
@@ -7834,6 +7869,7 @@ main (int argc, char **argv)
   log1p_test ();
   log2_test ();
   logb_test ();
+  logb_test_downward ();
   modf_test ();
   ilogb_test ();
   scalb_test ();
diff --git a/sysdeps/powerpc/powerpc32/Makefile
b/sysdeps/powerpc/powerpc32/Makefile
index aa2d0b9..638e177 100644
--- a/sysdeps/powerpc/powerpc32/Makefile
+++ b/sysdeps/powerpc/powerpc32/Makefile
@@ -42,3 +42,9 @@ ifeq ($(subdir),elf)
 # extra shared linker files to link only into dl-allobjs.so
 sysdep-rtld-routines += dl-start
 endif
+
+# BZ #887 logb for powerpc32 power4 ISA and earlier exhibits a negative sign
+# on zero from a downward round.
+ifeq ($(subdir),math)
+CFLAGS-s_logb.c += -frounding-math
+endif

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #21 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-03-26 20:43:10 UTC ---
I don't see why the test should be restricted to "double"; the correct 
behaviour it tests for is wanted for all floating-point types, not just 
"double".

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #22 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-26 20:51:10 UTC ---
(In reply to comment #21)
> I don't see why the test should be restricted to "double"; the correct 
> behaviour it tests for is wanted for all floating-point types, not just 
> "double".

I'll get rid of that guard.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #23 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-26 20:55:17 UTC ---
Created attachment 6302
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6302
preprocessed source for s_logb.c

For the benefit of the GCC folks who'll link to this bugz here's how s_logb.c
was built:

cd /home/ryanarn/glibc-git/glibc/math

/opt/at5.0/bin/gcc -m32 ../sysdeps/ieee754/ldbl-opt/s_logb.c -save-temps -c
-std=gnu99 -fgnu89-inline -O3 -Wall -Winline -Wwrite-strings
-fmerge-all-constants -g -mcpu=power4 -mnew-mnemonics -Wstrict-prototypes
-mlong-double-128  -fpic -frounding-math   -Wno-uninitialized
-D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include
-I/home/ryanarn/glibc-git/build/glibc32_power4/math
-I/home/ryanarn/glibc-git/build/glibc32_power4
-I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf
-I../sysdeps/unix/sysv/linux/powerpc/powerpc32/power4
-I../sysdeps/powerpc/powerpc32/power4/fpu -I../sysdeps/powerpc/powerpc32/power4
-I../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu
-I../sysdeps/powerpc/powerpc32/fpu
-I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32
-I../sysdeps/unix/sysv/linux/powerpc/powerpc32
-I../nptl/sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux/powerpc
-I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt
-I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
-I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc
-I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32
-I../sysdeps/powerpc/fpu -I../nptl/sysdeps/powerpc -I../sysdeps/powerpc
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl  -I.. -I../libio -I. 
-nostdinc -isystem /opt/at5.0/lib/gcc/powerpc64-linux/4.6.2/include -isystem
/opt/at5.0/lib/gcc/powerpc64-linux/4.6.2/include-fixed -isystem
/home/ryanarn/glibc-git/kernel_headers/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h  -DPIC -DSHARED -DNOT_IN_libc=1 -DIS_IN_libm=1    -o
/home/ryanarn/glibc-git/build/glibc32_power4/math/s_logb.os


Attached is the preprocessed source file.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #24 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-03-26 20:56:47 UTC ---
Created attachment 6303
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6303
Generated asm file for s_logb.c

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #25 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-04-25 22:01:13 UTC ---
A GCC fix to allow the fcfid insn to be used on power4 for both 32-bit and
64-bit should correct this problem without needing more cumbersome fixes.

r186387 | meissner | 2012-04-12 13:10:27 -0400 (Thu, 12 Apr 2012) | 16 lines
[gcc]
2012-04-11  Michael Meissner  <meissner@linux.vnet.ibm.com>
         PR target/52775
         * config/rs6000/rs6000.h (TARGET_FCFID): Add TARGET_PPC_GPOPT to
         the list of options to enable the FCFID instruction.
         (TARGET_EXTRA_BUILTINS): Adjust comment.
[gcc/testsuite]
2012-04-11  Michael Meissner  <meissner@linux.vnet.ibm.com>
         PR target/52775
         * gcc.target/powerpc/pr52775.c: New file.

I'll verify that this fixes the problem and submit my test-case soon.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

Ryan S. Arnold <rsa at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #26 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-04-26 18:15:43 UTC ---
The aforementioned GCC fix allows the usage of the fcfid instruction in 32-bit
mode for power4 which can be used in place the fsub which exhibits the
undesirable trait of a negative sign in downward rounding mode.

The following patch will simply detect and flag this issue in the GLIBC libm
testsuite in the future if GCC insn selection regresses for any reason.

2012-04-26  Ryan S. Arnold  <rsa@linux.vnet.ibm.com>

        [BZ #887]
        * math/libm-test.inc (logb_test_downward): New test to expose 
        erroneous negative sign on -0.0 result of logb[l](1) in FE_DOWNWARD
        rounding mode.

diff --git a/math/libm-test.inc b/math/libm-test.inc
index e0ac613..81de85b 100644
--- a/math/libm-test.inc
+++ b/math/libm-test.inc
@@ -5101,6 +5101,40 @@ logb_test (void)
   END (logb);
 }

+static void
+logb_test_downward (void)
+{
+  int save_round_mode;
+  errno = 0;
+
+  FUNC(logb) (0);
+  if (errno == ENOSYS)
+    /* Function not implemented.  */
+    return;
+
+  START (logb_downward);
+
+  save_round_mode = fegetround ();
+
+  if (!fesetround (FE_DOWNWARD))
+    {
+
+      /* IEEE 754-2008 says (section 5.3.3) that "logB(1) is +0.".  Libm
+       * should not return -0 from logb in any rounding mode.  PowerPC32 has
+       * failed with this test for power4 logb (and logbl on all PowerPC
+       * platforms) in the past due to instruction selection.  GCC PR 52775
+       * provides the availability of the fcfid insn in 32-bit mode which
+       * eliminates the use of fsub in this instance and prevents the negative
+       * signed 0.0.  */
+
+      /* BZ #887 .*/
+      TEST_f_f (logb, 1.000e+0, plus_zero);
+    }
+
+  fesetround (save_round_mode);
+
+  END (logb_downward);
+}

 static void
 lround_test (void)
@@ -8210,6 +8244,7 @@ main (int argc, char **argv)
   log1p_test ();
   log2_test ();
   logb_test ();
+  logb_test_downward ();
   modf_test ();
   ilogb_test ();
   scalb_test ();

Tested and verified fixed with gcc version 4.6.4 20120423 (prerelease)
[ibm/gcc-4_6-branch revision 186704] (GCC).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #27 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-04-26 18:53:26 UTC ---
That glibc testsuite patch still needs sending to libc-alpha for review / 
commit, if not already checked in.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #28 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-04-26 19:03:20 UTC ---
I'm working on the email right now.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[rsa at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #29 from Ryan S. Arnold <rsa at us dot ibm.com> 2012-04-27 16:31:07 UTC ---
Pushed upstream with a slight change:

commit a462cb63326595eb018e26ea415f8ddc1ed50730
Author: Ryan S. Arnold <rsa@linux.vnet.ibm.com>
Date:   Fri Apr 27 10:47:39 2012 -0500

    New test to expose erroneous negative sign on logb(1) (bug 887).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #30 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  a5a326f660c020a4f85ce2ca2a3a2ccb4be7a058 (commit)
      from  b821f414e480d7f9e097fa453b1c9bfd44d64316 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a5a326f660c020a4f85ce2ca2a3a2ccb4be7a058

commit a5a326f660c020a4f85ce2ca2a3a2ccb4be7a058
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Jan 7 22:41:58 2014 +0000

    Mark more libm tests with xfail-rounding:ldbl-128ibm.

    This patch marks more libm tests as expected to fail for ldbl-128ibm
    in non-default rounding modes.  Given this, my expm1l fix
    <https://sourceware.org/ml/libc-alpha/2014-01/msg00135.html> and my
    libgcc fix <http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00157.html>
    for spurious overflows, the remaining failures in test-ldouble.out
    (for powerpc32 hard float) are small ulps, spurious underflow and
    inexact exceptions (the former probably arising from libgcc bugs
    though I haven't checked each case; the latter are barely meaningful
    for this format anyway when basic arithmetic isn't correctly rounding,
    though most of them are probably GCC bug 59412 which doesn't actually
    involve long double), missing underflow exceptions from clog, ctan and
    ctanh (probably one of the known bugs for another function), and logb
    in round-downward mode (bug 887, though it's really a GCC bug that
    we're not currently working around).

    Tested for powerpc32 hard float.

        * math/auto-libm-test-in: Mark various tests with
        xfail-rounding:ldbl-128ibm.
        * math/auto-libm-test-out: Regenerated.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog               |    4 +
 math/auto-libm-test-in  |   40 ++-
 math/auto-libm-test-out |  832 +++++++++++++++++++++++-----------------------
 3 files changed, 443 insertions(+), 433 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=887

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #31 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Reopening to fix logb for older processors.

The GCC bug for the older processors is
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67771>.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=887

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brooks at gcc dot gnu.org

--- Comment #32 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
*** Bug 16423 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #33 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  bc3753638a1c3c93dea071414909ce2729e3ca50 (commit)
      from  57352c2201678ee52e7e8ea6fb6e115a9ec4e711 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=bc3753638a1c3c93dea071414909ce2729e3ca50

commit bc3753638a1c3c93dea071414909ce2729e3ca50
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Oct 5 17:46:50 2015 +0000

    Work around powerpc32 integer 0 converting to -0 (bug 887, bug 19049, bug
19050).

    On powerpc32 hard-float, older processors (ones where fcfid is not
    available for 32-bit code), GCC generates conversions from integers to
    floating point that wrongly convert integer 0 to -0 instead of +0 in
    FE_DOWNWARD mode.  This in turn results in logb and a few other
    functions wrongly returning -0 when they should return +0.

    This patch works around this issue in glibc as I proposed in
    <https://sourceware.org/ml/libc-alpha/2015-09/msg00728.html>, so that
    the affected functions can be correct and the affected tests pass in
    the absence of a GCC fix for this longstanding issue (GCC bug 67771 -
    if fixed, of course we can put in GCC version conditionals, and
    eventually phase out the workarounds).  A new macro
    FIX_INT_FP_CONVERT_ZERO is added in a new sysdeps header
    fix-int-fp-convert-zero.h, and the powerpc32/fpu version of that
    header defines the macro based on the results of a configure test for
    whether such conversions use the fcfid instruction.

    Tested for x86_64 (that installed stripped shared libraries are
    unchanged by the patch) and powerpc (that HAVE_PPC_FCFID comes out to
    0 as expected and that the relevant tests are fixed).  Also tested a
    build with GCC configured for -mcpu=power4 and verified that
    HAVE_PPC_FCFID comes out to 1 in that case.

    There are still some other issues to fix to get test-float and
    test-double passing cleanly for older powerpc32 processors (apart from
    the need for an ulps regeneration for powerpc).  (test-ldouble will be
    harder to get passing cleanly, but with a combination of selected
    fixes to ldbl-128ibm code that don't involve significant performance
    issues, allowing spurious underflow and inexact exceptions for that
    format, and lots of XFAILing for the default case of unpatched libgcc,
    it should be doable.)

        [BZ #887]
        [BZ #19049]
        [BZ #19050]
        * sysdeps/generic/fix-int-fp-convert-zero.h: New file.
        * sysdeps/ieee754/dbl-64/e_log10.c: Include
        <fix-int-fp-convert-zero.h>.
        (__ieee754_log10): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/dbl-64/e_log2.c: Include
        <fix-int-fp-convert-zero.h>.
        (__ieee754_log2): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/dbl-64/s_erf.c: Include
        <fix-int-fp-convert-zero.h>.
        (__erfc): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/dbl-64/s_logb.c: Include
        <fix-int-fp-convert-zero.h>.
        (__logb): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/flt-32/e_log10f.c: Include
        <fix-int-fp-convert-zero.h>.
        (__ieee754_log10f): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/flt-32/e_log2f.c: Include
        <fix-int-fp-convert-zero.h>.
        (__ieee754_log2f): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/flt-32/s_erff.c: Include
        <fix-int-fp-convert-zero.h>.
        (__erfcf): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/flt-32/s_logbf.c: Include
        <fix-int-fp-convert-zero.h>.
        (__logbf): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/ldbl-128ibm/s_erfl.c: Include
        <fix-int-fp-convert-zero.h>.
        (__erfcl): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/ieee754/ldbl-128ibm/s_logbl.c: Include
        <fix-int-fp-convert-zero.h>.
        (__logbl): Adjust signs as needed if FIX_INT_FP_CONVERT_ZERO.
        * sysdeps/powerpc/powerpc32/fpu/configure.ac: New file.
        * sysdeps/powerpc/powerpc32/fpu/configure: New generated file.
        * sysdeps/powerpc/powerpc32/fpu/fix-int-fp-convert-zero.h: New
        file.
        * config.h.in [_LIBC] (HAVE_PPC_FCFID): New macro.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |   42 ++++++++++++++++++++
 NEWS                                               |   18 ++++----
 config.h.in                                        |    3 +
 sysdeps/generic/fix-int-fp-convert-zero.h          |   27 +++++++++++++
 sysdeps/ieee754/dbl-64/e_log10.c                   |    3 +
 sysdeps/ieee754/dbl-64/e_log2.c                    |    7 +++-
 sysdeps/ieee754/dbl-64/s_erf.c                     |    6 ++-
 sysdeps/ieee754/dbl-64/s_logb.c                    |    3 +
 sysdeps/ieee754/flt-32/e_log10f.c                  |    3 +
 sysdeps/ieee754/flt-32/e_log2f.c                   |    8 +++-
 sysdeps/ieee754/flt-32/s_erff.c                    |    6 ++-
 sysdeps/ieee754/flt-32/s_logbf.c                   |    3 +
 sysdeps/ieee754/ldbl-128ibm/s_erfl.c               |    6 ++-
 sysdeps/ieee754/ldbl-128ibm/s_logbl.c              |    3 +
 sysdeps/powerpc/powerpc32/fpu/configure            |   29 +++++++++++++
 sysdeps/powerpc/powerpc32/fpu/configure.ac         |   18 ++++++++
 .../powerpc32/fpu/fix-int-fp-convert-zero.h        |   28 +++++++++++++
 17 files changed, 199 insertions(+), 14 deletions(-)
 create mode 100644 sysdeps/generic/fix-int-fp-convert-zero.h
 create mode 100644 sysdeps/powerpc/powerpc32/fpu/configure
 create mode 100644 sysdeps/powerpc/powerpc32/fpu/configure.ac
 create mode 100644 sysdeps/powerpc/powerpc32/fpu/fix-int-fp-convert-zero.h

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #34 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  a8133e197ec852cac46132efeeefae14489031f0 (commit)
      from  bc3753638a1c3c93dea071414909ce2729e3ca50 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a8133e197ec852cac46132efeeefae14489031f0

commit a8133e197ec852cac46132efeeefae14489031f0
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Oct 5 17:49:28 2015 +0000

    Don't list bug 887 as fixed for glibc 2.16.

-----------------------------------------------------------------------

Summary of changes:
 NEWS |   46 +++++++++++++++++++++++-----------------------
 1 files changed, 23 insertions(+), 23 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/887] Math library function "logb" and "nextafter" inconsistent

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=887

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|2.16                        |2.23

--- Comment #35 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
Actually fixed in glibc for older processors for 2.23.

-- 
You are receiving this mail because:
You are on the CC list for the bug.