Re: [PATCH] Remove alpha specific fmax, fmin to fix sNaN handling [BZ #20947]

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 1 Jan 2018, Adhemerval Zanella wrote:

> On 01/01/2018 13:06, Joseph Myers wrote:
> > On Mon, 1 Jan 2018, Aurelien Jarno wrote:
> > 
> >> Thanks for the review. ceil and floor have already been fixed in commits
> >> 062e53c195 and 65cc568cf5. What is left are many issues with the
> >> exceptions, mostly "Inexact" ones, but they are more difficult to fix.
> > 
> > If you have missing "inexact" for functions that require it to be raised, 
> > building those particular functions with -mieee-with-inexact (which some 
> > functions and tests already use) would be appropriate.
> > 
> 
> Indeed I was referring to Inexact exceptions being generated.  And
> unfortunately adding -mieee-with-inexact on s_ceil{f} does not seems
> to fix the issues on the environment I have access (gcc version 6.3.0,
> Alpha EV68CB). Also, the same compiler flag does not help on fma{f}.

In the case of ceil, inexact should never be generated.  Since the alpha 
ceil implementations work entirely with asm which does not use /i to 
enable inexact exceptions, I'm not sure why they should generate such 
exceptions spuriously.  What failures are you seeing exactly - every case 
of noninteger arguments to ceil / ceilf, or only some such cases, or even 
cases of integer arguments?

Possibly some cases of the instructions used in ceil / ceilf are trapping 
to the kernel?  It looks like the alpha floating-point emulation in the 
kernel (arch/alpha/math-emu/math.c) does not decode the TRP field at all, 
and so would wrongly set inexact even when the instruction semantics 
should not set it.  If so, the kernel bug would need to be fixed for code 
relying on inexact not being set to work.

That however does not explain issues for fma / fmaf.  What do you see 
there - spurious inexact, missing inexact, wrong results?  The use of 
-mieee-with-inexact ought to ensure instructions are generated that set 
"inexact" appropriately, and unless it's set appropriately, wrong results 
can occur because the round-to-odd implementation relies on correct 
setting of inexact.  fmaf in particular is very simple, so as long as the 
right instructions are used and nothing gets reordered past the libc_fe* 
calls, not much should be able to go wrong.

-- 
Joseph S. Myers
joseph@codesourcery.com