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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 01/01/2018 19:59, Joseph Myers wrote:
> 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?

The ceil/ceilf issues are in attachments (ran with s_ceil{f} built with
-mieee-with-inexact).

> 
> 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.

I am not sure if these are related to kernel emulation, although from kernel
config the math is indeed add as a builtin object.  I am trying to check 
if it is the case.

> 
> 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.

The issues I am seeing on alpha for fma/fmaf are also in attachments.

Attachment: test-double-ceil.out
Description: Text document

Attachment: test-float-ceil.out
Description: Text document

Attachment: test-double-fma.out
Description: Text document

Attachment: test-float-fma.out
Description: Text document