This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Call math_opt_barrier inside if
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 14 Jan 2016 22:38:02 +0000
- Subject: Re: [PATCH] Call math_opt_barrier inside if
- Authentication-results: sourceware.org; auth=none
- References: <20160114214145 dot GA22984 at intel dot com> <alpine dot DEB dot 2 dot 10 dot 1601142212190 dot 27845 at digraph dot polyomino dot org dot uk> <CAMe9rOoTt7VqM_R=gOr_AYZ4yvPhBimp6R3xM4a5W0Tu98=CBA at mail dot gmail dot com>
On Thu, 14 Jan 2016, H.J. Lu wrote:
> On Thu, Jan 14, 2016 at 2:13 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Thu, 14 Jan 2016, H.J. Lu wrote:
> >
> >> Since floating-point operation may trigger floating-point exceptions,
> >> we call math_opt_barrier inside if to prevent code motion.
> >>
> >> Tested on x86-64. OK for trunk?
> >
> > Please send a patch updating all implementations for which this issue is
> > applicable.
>
> There are
>
> dbl-64/e_sqrt.c: libc_feholdexcept_setround (&env, FE_TONEAREST);
> dbl-64/s_fma.c: libc_feholdexcept_setround (&env, FE_TONEAREST);
> dbl-64/s_fmaf.c: libc_feholdexcept_setround (&env, FE_TOWARDZERO);
>
> under sysdeps/ieee754. dbl-64/s_fma.c is the only one with this
> problem.
I disagree with that analysis. The question isn't whether there's a call
to a particular internal interface. The question is whether there are
conditionals on arithmetic, such that the arithmetic is exact in the
conditional case but may be inexact if moved before the conditional. I
think at least ldbl-96/s_fmal.c, ldbl-96/s_fma.c and ldbl-128/s_fmal.c
have the same issue.
--
Joseph S. Myers
joseph@codesourcery.com