[Bug math/19465] Wrong code with -Os

["hjl.tools at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19465

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #2)
> On Thu, 14 Jan 2016, hjl.tools at gmail dot com wrote:
> 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19465
> > 
> > --- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
> > sysdeps/ieee754/dbl-64/s_fma.c has
> > 
> > feclearexcept (FE_INEXACT);
> > ...
> > int j = libc_feupdateenv_test (&env, FE_INEXACT) != 0;
> > 
> > But env isn't updated after feclearexcept.
> 
> feclearexcept isn't meant to touch env.
> 
> env is meant to store exactly the environment before 
> libc_feholdexcept_setround - that is, with "inexact" raised if and only if 
> it was already raised on entry to fma.  feclearexcept affects the live 
> environment, not the saved environment, Then libc_feupdateenv_test tests 
> whether FE_INEXACT is set in the live environment (that is, was set by an 
> operation that executed after feclearexcept), and restores the saved 
> environment but with the exceptions from the live environment (which 
> should not include anything other than "inexact") merged in.
> 
> If -Os affects exceptions, that suggests that something in this 
> implementation is missing a barrier (math_force_eval / math_opt_barrier 
> etc.) to prevent code motion past changes to / tests of floating-point 
> state.  Any fix would probably be to add such a barrier.  If such a fix is 
> needed, it's important to check all the fma* implementations to see if 
> others need a corresponding fix as well.

With -Os,

 /* Ensure correct sign of exact 0 + 0.  */
  if (__glibc_unlikely ((x == 0 || y == 0) && z == 0)) 
    return x * y + z;

causes FE_INEXACT:

   0x00007ffff7b0f10e <+1154>:  xorps  %xmm3,%xmm3
   0x00007ffff7b0f111 <+1157>:  mov    $0x0,%dl
   0x00007ffff7b0f113 <+1159>:  movapd %xmm5,%xmm0
   0x00007ffff7b0f117 <+1163>:  ucomisd %xmm3,%xmm5
   0x00007ffff7b0f11b <+1167>:  movapd %xmm3,%xmm8
   0x00007ffff7b0f120 <+1172>:  mulsd  %xmm1,%xmm0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  This triggers FE_INEXACT.

(gdb) p $xmm0
$42 = {v4_float = {-nan(0x7ffffe), 1.87499988, 0, 0}, v2_double = {
    0.99999999999999978, 0}, v16_int8 = {-2, -1, -1, -1, -1, -1, -17, 63, 0, 
    0, 0, 0, 0, 0, 0, 0}, v8_int16 = {-2, -1, -1, 16367, 0, 0, 0, 0}, 
  v4_int32 = {-2, 1072693247, 0, 0}, v2_int64 = {4607182418800017406, 0}, 
  uint128 = 4607182418800017406}
(gdb) p $xmm1
$43 = {v4_float = {-nan(0x7fffff), -1.87499988, 0, 0}, v2_double = {
    -0.99999999999999989, 0}, v16_int8 = {-1, -1, -1, -1, -1, -1, -17, -65, 0, 
    0, 0, 0, 0, 0, 0, 0}, v8_int16 = {-1, -1, -1, -16401, 0, 0, 0, 0}, 
  v4_int32 = {-1, -1074790401, 0, 0}, v2_int64 = {-4616189618054758401, 0}, 
  uint128 = 13830554455654793215}
(gdb) 

=> 0x00007ffff7b0f124 <+1176>:  setnp  %cl
   0x00007ffff7b0f127 <+1179>:  cmovne %edx,%ecx
   0x00007ffff7b0f12a <+1182>:  ucomisd %xmm3,%xmm1
   0x00007ffff7b0f12e <+1186>:  setnp  %al
   0x00007ffff7b0f131 <+1189>:  cmovne %edx,%eax
   0x00007ffff7b0f134 <+1192>:  or     %al,%cl

-- 
You are receiving this mail because:
You are on the CC list for the bug.