Opened 6 years ago

Closed 5 years ago

#9962 closed bug (fixed)

pow returns nan instead of inf for large results

Reported by: markh Owned by: jessicah
Priority: normal Milestone: R1
Component: System/libroot.so Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

When calculating large results with pow, it returns nan instead of inf. This causes one check in postgresql to fail.

For example: pow(-1004.3, 1e200) returns nan on Haiku, while inf is expected.

I created a small test program that shows the behaviour and attached it to this ticket.

Ingo told me that the problem is probably in glibc, but I'm not sure which component to select from the list.

Attachments (2)

main.cpp (1.6 KB) - added by markh 6 years ago.
Small example of pow returning nan instead of the expected inf
0001-libroot.so-update-glibc-s-e_pow.S-on-x86.-Fixes-9962.patch (9.9 KB) - added by jessicah 5 years ago.

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by markh

Attachment: main.cpp added

Small example of pow returning nan instead of the expected inf

comment:1 Changed 6 years ago by anevilyak

Component: - GeneralSystem/libroot.so
Owner: changed from nobody to axeld

comment:2 Changed 6 years ago by markh

axeld: Do you have time to look at this? I think this is the last issue I need to get fixed before I can attempt to get my changes in the Postgresql tree. If they accept the changes, postgresql could be built from the official source.

comment:3 Changed 5 years ago by jessicah

Owner: changed from axeld to jessicah
Status: newassigned

comment:4 Changed 5 years ago by jessicah

Has a Patch: set

comment:5 Changed 5 years ago by korli

We should probably update a few other files (for powf and powl), x86_64 is also likely affected. Giving the exact source revision in the commit message would be nice (or simply glibc 2.19 if that's the source tag)

comment:6 Changed 5 years ago by jessicah

Could we just update the entire math section of glibc? I know we use an old glibc for gcc2 reasons, so don't know if that's feasible or not.

comment:7 Changed 5 years ago by pulkomandy

The reason we use an old glibc is not gcc2, but binary compatibility. The version that was used in BeOS unfortunately leaked some symbols that are not part of the official API, so we must stay compatible with those. So, updating the glibc must be done only with great care. We used to have a port of the abi-compliance-checker, which is the tool used by the glibc project to test for such changes. It should be possible to run it (even from another OS, I think the tool works at source level) to check such changes.

There is also a risk of the changes to the math part requiring updates to other parts of the lib, and so on.

IIRC, however, the x86_64 version of glibc actually uses assembler files from a newer glibc version, as our old one didn't have any x86_64 support. Looking at the commit logs for that may provide some hints on what's possible, but the x86_64 version didn't have to retain the binary compatibility.

comment:8 Changed 5 years ago by markh

As mentioned on the haiku-development mailing list, pow now returns inf as expected and the Postgresql "make check" tests now run without errors. I will do some more testing in the next few days to get a better idea if it works correctly.

comment:9 Changed 5 years ago by jessicah

Resolution: fixed
Status: assignedclosed

Fixed in hrev47328

Note: See TracTickets for help on using tickets.