From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11805 invoked by alias); 13 Apr 2009 05:40:17 -0000 Received: (qmail 11207 invoked by uid 48); 13 Apr 2009 05:40:01 -0000 Date: Mon, 13 Apr 2009 05:40:00 -0000 From: "adam at spicenitz dot org" To: glibc-bugs@sources.redhat.com Message-ID: <20090413054000.10064.adam@spicenitz.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug ports/10064] New: ARM fesetround doesn't work as expected with VFP present but unused X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00069.txt.bz2 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. -- Summary: ARM fesetround doesn't work as expected with VFP present but unused Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ports AssignedTo: roland at gnu dot org ReportedBy: adam at spicenitz dot org CC: glibc-bugs at sources dot redhat dot com GCC host triplet: armv5tel-redhat-linux-gnueabi http://sourceware.org/bugzilla/show_bug.cgi?id=10064 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.