This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |