| Message ID | CAFULd4bDzGPgSoGh-20zL4AOfTfoVoY_H12DJxvjdy-KGLo_Xg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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).
On Tue, Sep 23, 2014 at 7:57 PM, Joseph S. Myers <joseph@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.
On Tue, 23 Sep 2014, Uros Bizjak wrote: > On Tue, Sep 23, 2014 at 7:57 PM, Joseph S. Myers > <joseph@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).
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 >> <joseph@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...
On Tue, Sep 23, 2014 at 8:40 PM, Marc Glisse <marc.glisse@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.
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...
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; }
Hello! Attached patch avoids triggering denormal exceptions when FP insns are used to check for non-zero denormal values. 2014-09-23 Uros Bizjak <ubizjak@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.