This is the mail archive of the
mailing list for the glibc project.
Re: RFC: avoiding "inexact" from x86 ceil / floor / trunc
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Wed, 25 May 2016 16:28:40 +0100
- Subject: Re: RFC: avoiding "inexact" from x86 ceil / floor / trunc
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <alpine dot DEB dot 2 dot 20 dot 1605251423310 dot 2813 at digraph dot polyomino dot org dot uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 25/05/16 15:40, Joseph Myers wrote:
> My question is: should we do anything special in this case to optimize
> things for code that doesn't care about "inexact" being set? It's not
> clear we have a good way to tell; GCC doesn't predefine a macro for
> -fno-trapping-math. And __STDC_WANT_IEC_60559_BFP_EXT__ is about
> declaring new identifiers, not changing semantics for existing ones.
existing code is unlikely to care about inexact since c99 did not
require silent conversion and the historical practice was to raise
inexact (and even that was not reliable because the compiler does
not handle FENV_ACCESS).
so changing the code to follow ts-18861 just makes things slower.
> My inclination is that handling the case of not caring about "inexact" is
> better done in the compiler, in which case these functions can be inlined
> rather than exporting separate versions from glibc. Unfortunately GCC
> doesn't currently inline these functions in all the cases where it could
> (or have an option to select TS 18661-1 semantics):
yes, if the compiler can handle this (and doesn't care about
inexact by default for -std=c99/c11) that sounds acceptable.
otherwise i would not be keen to fix this correctness issue.