Bug 10064 - [arm] ARM fesetround doesn't work as expected with VFP present but unused
Summary: [arm] ARM fesetround doesn't work as expected with VFP present but unused
Status: SUSPENDED
Alias: None
Product: glibc
Classification: Unclassified
Component: math (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-13 05:40 UTC by Adam Goode
Modified: 2014-07-01 07:19 UTC (History)
1 user (show)

See Also:
Host: armv5tel-redhat-linux-gnueabi
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Goode 2009-04-13 05:40:00 UTC
When using software floating point, fesetround should return error on all but
the default rounding mode. When VFP hardware happens to be present, fesetround
will program the VFP to the rounding mode, and not return error. Unfortunately,
software floating point rounding mode is not changed. This causes programs which
would otherwise detect the failure to change rounding mode to fail later in
subtle ways.

How to fix this? Is there a way to detect if an application is not using the
VFP? I see some ELF tags that might be relevant. Otherwise, could glibc
implement the aeabi floating point helper functions instead of gcc? Then, it
could choose to use the VFP when present in hardware, or use the assembly
version when there is no VFP.
Comment 1 Joseph Myers 2012-02-15 21:57:45 UTC
Discussion at <http://sourceware.org/ml/libc-ports/2009-04/subjects.html#00019>; I don't think there's any ideal solution for all cases, and both GCC and glibc will probably be involved in any improvement here.
Comment 2 Joseph Myers 2012-02-19 01:30:57 UTC
Suspending, given the likely tricky interactions with other toolchain components.