[4/4] alpha: expect test-float32x-float64-div to fail
Checks
| Context |
Check |
Description |
| redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Test passed
|
Commit Message
_Float32x and _Float64 are both binary64 on Alpha, so this narrowing
divide is a plain divide and the hardware alone decides whether to signal
underflow.
IEEE 754 determines tininess after rounding from the result rounded as if
the exponent range were unbounded, while Alpha determines it from the
delivered result. The two differ for a quotient that is tiny but rounds
up to the smallest normal, as in DBL_MIN / (1 + 2^-52) under a rounding
mode that rounds away from zero: the binade below DBL_MIN has a finer
spacing than the subnormals, so the unbounded rounding stays below
DBL_MIN and the result is tiny, but the delivered result is DBL_MIN and
looks normal. Alpha signals no underflow for it.
Nothing in software can correct this. The hardware detects no underflow,
so no software completion trap is taken and the kernel emulation never
runs, and as the operation is not really narrowing there is no wider
intermediate for libm to examine.
---
sysdeps/alpha/Makefile | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Comments
On 03/08/26 20:55, Matt Turner wrote:
> _Float32x and _Float64 are both binary64 on Alpha, so this narrowing
> divide is a plain divide and the hardware alone decides whether to signal
> underflow.
>
> IEEE 754 determines tininess after rounding from the result rounded as if
> the exponent range were unbounded, while Alpha determines it from the
> delivered result. The two differ for a quotient that is tiny but rounds
> up to the smallest normal, as in DBL_MIN / (1 + 2^-52) under a rounding
> mode that rounds away from zero: the binade below DBL_MIN has a finer
> spacing than the subnormals, so the unbounded rounding stays below
> DBL_MIN and the result is tiny, but the delivered result is DBL_MIN and
> looks normal. Alpha signals no underflow for it.
>
> Nothing in software can correct this. The hardware detects no underflow,
> so no software completion trap is taken and the kernel emulation never
> runs, and as the operation is not really narrowing there is no wider
> intermediate for libm to examine.
LGTM, thanks. I wonder if we should add a header like tininess.h to handle
this operation in a generic manner and avoid the xfail definition; but it
seems really alpha-specific.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> ---
> sysdeps/alpha/Makefile | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git ./sysdeps/alpha/Makefile ./sysdeps/alpha/Makefile
> index 60a369e255..faa59ab27a 100644
> --- ./sysdeps/alpha/Makefile
> +++ ./sysdeps/alpha/Makefile
> @@ -53,6 +53,20 @@ CFLAGS-s_lrint.c += -mieee-with-inexact
> CFLAGS-test-misc.c += -mieee-with-inexact
> # Avoid "conflicting types for built-in function" warnings
> CFLAGS-s_isnan.c += -fno-builtin-isnanf
> +
> +# _Float32x and _Float64 are both binary64 on Alpha, so this narrowing
> +# divide is a plain divide and the hardware alone decides whether to
> +# signal underflow. IEEE 754 determines tininess after rounding from the
> +# result rounded as if the exponent range were unbounded, but Alpha
> +# determines it from the delivered result. For a quotient that is tiny
> +# but rounds up to the smallest normal -- DBL_MIN / (1 + 2^-52) under a
> +# rounding mode that rounds away from zero -- the unbounded rounding
> +# stays below DBL_MIN, because that binade has a finer spacing than the
> +# subnormals, while the delivered result is DBL_MIN and looks normal.
> +# Alpha raises no underflow for it. No trap is taken, so the kernel
> +# emulation cannot correct this, and the operation has no wider
> +# intermediate for libm to examine.
> +test-xfail-test-float32x-float64-div = yes
> endif
>
> # Build everything with full IEEE math support, and with dynamic rounding;
@@ -53,6 +53,20 @@ CFLAGS-s_lrint.c += -mieee-with-inexact
CFLAGS-test-misc.c += -mieee-with-inexact
# Avoid "conflicting types for built-in function" warnings
CFLAGS-s_isnan.c += -fno-builtin-isnanf
+
+# _Float32x and _Float64 are both binary64 on Alpha, so this narrowing
+# divide is a plain divide and the hardware alone decides whether to
+# signal underflow. IEEE 754 determines tininess after rounding from the
+# result rounded as if the exponent range were unbounded, but Alpha
+# determines it from the delivered result. For a quotient that is tiny
+# but rounds up to the smallest normal -- DBL_MIN / (1 + 2^-52) under a
+# rounding mode that rounds away from zero -- the unbounded rounding
+# stays below DBL_MIN, because that binade has a finer spacing than the
+# subnormals, while the delivered result is DBL_MIN and looks normal.
+# Alpha raises no underflow for it. No trap is taken, so the kernel
+# emulation cannot correct this, and the operation has no wider
+# intermediate for libm to examine.
+test-xfail-test-float32x-float64-div = yes
endif
# Build everything with full IEEE math support, and with dynamic rounding;