Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Tue, Sep 23, 2014 at 8:40 PM, Marc Glisse marc.gli...@inria.fr wrote: Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. But I thought the point of the test was to verify that the compiler's understanding of existence of subnormal values was consistent with the processor. If the processor is in a mode supporting such values, the exceptions should be masked. That is, the present test should pass unconditionally, if it doesn't pass that indicates a bug (which might be appropriate for XFAILing). Alpha needs special instruction mode to process denormals. Without this special mode the insn traps as soon as denormal value is processed. Yes, but I thought the point of that PR was that unless -mieee was given to support such values, *_TRUE_MIN should be the same as *_MIN, reflecting that they aren't supported. And so the failure is showing that this bug is present (and so XFAILing with a comment referring to the bug is appropriate, rather than changing the test to pass). That's also my understanding, I am sorry Uros that I wasn't clear enough in the PR... I see the intention now. However, alpha *does* support all IEEE features, the only problem is in its default model, which is for some reason High-Performance IEEE-Format Arithmetic (please see alpha AHB [1], section 4.7.6.5). This model does not require the overhead of an operating system completion handler and can be the fastest of the three IEEE models.. Unfortunately, this model also notifies applications of all exceptional floating-point operations. Denormals are considered non-finite IEEE values, so they trap. When the target is in certain high-speed mode, it is up to the user to obey all the limitations, in this particular case, that only IEEE finite numbers are provided. This is not the case with the original testcase, so I'd say that the test is out of specs. It beats me, why -mieee is not the default on alpha, since current default suits -ffast-math more, but it looks that we have to live with this mess. To avoid traps on denormals, -mieee has to be specified. This option enables FP software completion that completes denormal handling, so there is no need to notify application IMO, instead of XFAILing the test, we should simply provide -mieee. __*_DENORM_MIN__ should indeed apply to the underlying FP format, not to sme target-dependent model and its implementation details. [1] http://www.compaq.com/cpq-alphaserver/technology/literature/alphaahb.pdf Uros.
Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Wed, 24 Sep 2014, Uros Bizjak wrote: However, alpha *does* support all IEEE features, the only problem is in its default model, which is for some reason High-Performance IEEE-Format Arithmetic (please see alpha AHB [1], section 4.7.6.5). This model does not require the overhead of an operating system completion handler and can be the fastest of the three IEEE models.. Unfortunately, this model also notifies applications of all exceptional floating-point operations. Denormals are considered non-finite IEEE values, so they trap. When the target is in certain high-speed mode, it is up to the user to obey all the limitations, in this particular case, that only IEEE finite numbers are provided. This is not the case with the original testcase, so I'd say that the test is out of specs. It beats me, why -mieee is not the default on alpha, since current default suits -ffast-math more, but it looks that we have to live with this mess. (I believe -mieee is the default on some alpha platforms, maybe debian or bsd?) To avoid traps on denormals, -mieee has to be specified. This option enables FP software completion that completes denormal handling, so there is no need to notify application IMO, instead of XFAILing the test, we should simply provide -mieee. __*_DENORM_MIN__ should indeed apply to the underlying FP format, not to sme target-dependent model and its implementation details. [1] http://www.compaq.com/cpq-alphaserver/technology/literature/alphaahb.pdf In 4.7.6.5, I see: Underflow results are set to zero. so this is a functional model without denormals. According to the C11 standard, this means DBL_HAS_SUBNORM should be 0 and DBL_TRUE_MIN should be the same as DBL_MIN. The same is probably true on x86 with -ffast-math. Giving DBL_TRUE_MIN an unusable value (zero or trapping) is not very useful, while providing the real usable minimum lets users do something meaningful with it. The main issue is using incompatible flags in different objects or at link time... -- Marc Glisse
[PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
Hello! Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. 2014-09-23 Uros Bizjak ubiz...@gmail.com PR target/58757 * gcc.dg/c11-true_min-1.c (checkz): Add. (main): Call checkz to check value for zero. Patch was tested on x86_64 {,-m32} and alphaev68-linux-gnu. OK for mainline? Uros. Index: gcc.dg/c11-true_min-1.c === --- gcc.dg/c11-true_min-1.c (revision 215476) +++ gcc.dg/c11-true_min-1.c (working copy) @@ -7,11 +7,25 @@ #include float.h -int main(){ +int +__attribute__((noinline, noclone)) +checkz (const char *ptr, int n) +{ + for ( ; n 0; --n) +if (*(ptr++) != 0) + return 0; + return 1; +} + +int main () +{ volatile float f = FLT_TRUE_MIN; volatile double d = DBL_TRUE_MIN; volatile long double l = LDBL_TRUE_MIN; - if (f == 0 || d == 0 || l == 0) + + if (checkz ((const char *) f, sizeof(f)) +|| checkz ((const char *) d, sizeof(d)) +|| checkz ((const char *) l, sizeof (l))) __builtin_abort (); return 0; }
Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Tue, 23 Sep 2014, Uros Bizjak wrote: Hello! Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. But I thought the point of the test was to verify that the compiler's understanding of existence of subnormal values was consistent with the processor. If the processor is in a mode supporting such values, the exceptions should be masked. That is, the present test should pass unconditionally, if it doesn't pass that indicates a bug (which might be appropriate for XFAILing). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Tue, Sep 23, 2014 at 7:57 PM, Joseph S. Myers jos...@codesourcery.com wrote: Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. But I thought the point of the test was to verify that the compiler's understanding of existence of subnormal values was consistent with the processor. If the processor is in a mode supporting such values, the exceptions should be masked. That is, the present test should pass unconditionally, if it doesn't pass that indicates a bug (which might be appropriate for XFAILing). Alpha needs special instruction mode to process denormals. Without this special mode the insn traps as soon as denormal value is processed. Uros.
Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Tue, 23 Sep 2014, Uros Bizjak wrote: On Tue, Sep 23, 2014 at 7:57 PM, Joseph S. Myers jos...@codesourcery.com wrote: Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. But I thought the point of the test was to verify that the compiler's understanding of existence of subnormal values was consistent with the processor. If the processor is in a mode supporting such values, the exceptions should be masked. That is, the present test should pass unconditionally, if it doesn't pass that indicates a bug (which might be appropriate for XFAILing). Alpha needs special instruction mode to process denormals. Without this special mode the insn traps as soon as denormal value is processed. Yes, but I thought the point of that PR was that unless -mieee was given to support such values, *_TRUE_MIN should be the same as *_MIN, reflecting that they aren't supported. And so the failure is showing that this bug is present (and so XFAILing with a comment referring to the bug is appropriate, rather than changing the test to pass). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, testsuite]: PR 58757: Check for FP denormal values without triggering denormal exceptions
On Tue, 23 Sep 2014, Joseph S. Myers wrote: On Tue, 23 Sep 2014, Uros Bizjak wrote: On Tue, Sep 23, 2014 at 7:57 PM, Joseph S. Myers jos...@codesourcery.com wrote: Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. But I thought the point of the test was to verify that the compiler's understanding of existence of subnormal values was consistent with the processor. If the processor is in a mode supporting such values, the exceptions should be masked. That is, the present test should pass unconditionally, if it doesn't pass that indicates a bug (which might be appropriate for XFAILing). Alpha needs special instruction mode to process denormals. Without this special mode the insn traps as soon as denormal value is processed. Yes, but I thought the point of that PR was that unless -mieee was given to support such values, *_TRUE_MIN should be the same as *_MIN, reflecting that they aren't supported. And so the failure is showing that this bug is present (and so XFAILing with a comment referring to the bug is appropriate, rather than changing the test to pass). That's also my understanding, I am sorry Uros that I wasn't clear enough in the PR... -- Marc Glisse