Bug 6814 – expm1() raises bogus invalid exception

Bug 6814 - expm1() raises bogus invalid exception


Summary:	expm1() raises bogus invalid exception

Status:	RESOLVED FIXED

Product:	glibc
Classification:	Unclassified
Component:	math
Version:	unspecified

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Andreas Jaeger

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-08-04 04:41 UTC by Michael Kerrisk
Modified:	2012-02-29 22:33 UTC (History)
CC List:	1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
test program (11.52 KB, text/plain) 2008-08-04 04:49 UTC, Michael Kerrisk	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Michael Kerrisk 2008-08-04 04:41:39 UTC

For certain large values of x, expm1() returns a bogus FE_INVALID exception and
returns a NaN instead of positive invinity.

Comment 1 Michael Kerrisk 2008-08-04 04:49:03 UTC

Created attachment 2885 [details]
test program

Comment 2 Michael Kerrisk 2008-08-04 04:49:16 UTC

$ /tmp/mt_expm1 1e5
errno == 0
fetestexcept() says:  FE_INVALID FE_OVERFLOW FE_INEXACT
expm1(1.00000000000000000e+05)=nan
0 FE_OVERFLOW nan

$ /tmp/mt_expm1 1.00199970127e5
errno == 0
fetestexcept() says:  FE_INVALID FE_OVERFLOW FE_INEXACT
expm1(1.00199970126999993e+05)=nan
0 FE_OVERFLOW nan

$ /tmp/mt_expm1 1.00199970128e5
errno == 0
fetestexcept() says:  FE_OVERFLOW FE_INEXACT
expm1(1.00199970128000001e+05)=inf
0 FE_OVERFLOW +inf

Comment 3 Michael Kerrisk 2008-08-04 04:50:14 UTC

Comment #2 should have started with thw words: "The first two runs below
demonstrate the problem:"

Comment 4 Joseph Myers 2012-02-29 22:33:42 UTC

This appears to have been fixed, probably by various changes in 2009 (there is a test in the testsuite of expm1 overflow, which will verify there is no such inappropriate exception, and that test was added in 2009).  However, the OVERFLOW exception for expm1 seems to have disappeared on x86, so I've filed bug 13787 for that problem.