Bug 369 - pow problems on x86

Bug#:

369 alias:

Hardware:

Reporter:

Zoltan Varga <vargaz@gmail.com>

Host:

Target:

Build:

Product:

Add CC:

Component:

Version:

CC:

Remove selected CCs

Status:

ASSIGNED

Priority:

Resolution:

Severity:

Assigned To:

Ulrich Drepper <drepper@redhat.com>

Target Milestone:

Flags:			Requestee:
	backport		()
	examined		()
	testsuite		()

Summary:

Keywords:

Attachment	Description	Type	Created	Actions
pow.diff	patch for pow to return inf/0 for (-2,+/-1E300)	patch	2006-08-31 22:27	Edit \| Diff
pow.diff	patch for pow to return inf/0 for (-2,+/-1E300)	patch	2006-08-31 22:32	Edit \| Diff
Create a New Attachment (proposed patch, testcase, etc.)			View All

Bug 369 depends on:			Show dependency tree Show dependency graph
Bug 369 blocks:			Show dependency tree Show dependency graph

Additional Comments:

Leave as ASSIGNED
Mark bug as waiting for feedback
Mark bug as suspended
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
Reassign bug to owner of selected component

View Bug Activity | Format For Printing

Description:

Last confirmed: 0000-00-00 00:00

Opened: 2004-09-06 12:23

Consider the following test program:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#include <stdio.h>
#include <math.h>

void main() {
        double d;

        d = pow (-2, 1E300);
        printf ("D: %f.\n", d);

        d = pow (-2, -1E300);
        printf ("D: %f.\n", d);
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Under x86 linux, this prints out:

D: nan.
D: nan

I think the answer should be +inf and 0, respectively. Both
solaris,
windows, and the IBM Accurate Portable Mathematical library
returns
these values, so I think this might be a bug in the assembly
language
pow routine in glibc.

------- Additional Comment #1 From Andreas Jaeger 2004-12-18 15:37 -------

The report is confirmed.  On other platforms we get the expected result.

Uli, could you look into this, please?

------- Additional Comment #2 From Steven Bosscher 2006-05-07 14:57 -------

It seems I've run into this one now, too.  What happened to this bug?

------- Additional Comment #3 From Nikolay Zhuravlev 2006-06-15 09:17 -------

I built glibc from CVS on 2006/06/14 and the bug is still there.
I think the culprit is the assembler code in __ieee754_pow.

POSIX wants HUGE_VAL for pow(-2, 1E300).

------- Additional Comment #4 From Nikolay Zhuravlev 2006-06-15 09:23 -------

Changed version to 'unspecified' since it is in the trunk

------- Additional Comment #5 From Pete Eberlein 2006-08-31 22:27 -------

Created an attachment (id=1269)
patch for pow to return inf/0 for (-2,+/-1E300)

I've created a patch to return inf for pow(-2,1E300) and 0 for pow(-2,-1E300). 
This patch modifies the function to use |x| and filter the result if x < 0,
keeping inf or zero, otherwise return NaN.

------- Additional Comment #6 From Pete Eberlein 2006-08-31 22:32 -------

Created an attachment (id=1270)
patch for pow to return inf/0 for (-2,+/-1E300)

oops, fixing the diff since it had some control chars accidentally pasted into
the file.

------- Additional Comment #7 From Ismail "cartman" Donmez 2007-12-15 09:46 -------

Still affects glibc 2.7

------- Additional Comment #8 From Michael Kerrisk 2008-07-30 09:17 -------

Still present in glibc 2.8