View Bug Activity | Format For Printing
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.
Created an attachment (id=470) A propsed patch to fix bug in logb() function on powerpc arch.
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?
Created an attachment (id=559) proposed patch for nextafter() for powerpc A proposed fix for a bug in nextafter() librray function.
Ping. Can anybody verify this patch, please?
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.
Ping.
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.
Created an attachment (id=1339) logb test case demonstrating the described behavior The included test case demonstrates the described behavior.
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.