[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.