This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AArch64 patches for glibc master.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at linaro dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 16 Dec 2013 18:02:04 +0000
- Subject: Re: AArch64 patches for glibc master.
- Authentication-results: sourceware.org; auth=none
- References: <52A60A93 dot 1050402 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1312091852010 dot 17984 at digraph dot polyomino dot org dot uk> <CABXK9nesQq-Pzf58dpvpvbguntm7M8585nGMH=oZuntKZoa7nw at mail dot gmail dot com>
On Wed, 11 Dec 2013, Marcus Shawcroft wrote:
> Inspection of sysdeps/ieee754/dbl-64/Makefile suggests that we assume
> -ffp-contract=fast and target specific source files with
> -ffp-contract=off rather than taking the conservative approach of
> defaulting to -ffp-contract=off and calling out individual files with
> -ffp-contract=fast.
>
> Extending the existing mechanism to pass -ffp-contract=off for
> e_sqrt.c is trivial, but is this the right approach, I'm not sure how
> to go about proving that we don't have similar issues lurking latent
> elsewhere in ieee754/* which may surface when a future version of gcc
> figures out how to make more extensive use of fused multiply
> instructions.
It's quite possible that some architecture-specific libm files in fact
rely on contracting taking place, if written for architectures known to
have fused multiply-add.
I think you should arrange for -ffp-contract=off to be used for this
particular file, and add an entry to the libm todo list on the wiki for
reviewing C libm files to identify whether they use precision extension
techniques that may rely on contracting not occurring; rely on
contracting; or are indifferent to it.
--
Joseph S. Myers
joseph@codesourcery.com