From: Carlos O'Donell <carlos@redhat.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
libc-alpha@sourceware.org, Bruno Haible <bruno@clisp.org>
Subject: Re: [PATCH v2 1/7] powerpc: Do not raise exception traps for fesetexcept/fesetexceptflag (BZ 30988)
Date: Tue, 19 Dec 2023 09:57:37 -0500 [thread overview]
Message-ID: <990d5b9b-b966-fa7e-5fd8-44e1b5902a89@redhat.com> (raw)
In-Reply-To: <578ae9cd-a47a-47a6-b17d-646ed3d97e46@linaro.org>
On 11/27/23 08:46, Adhemerval Zanella Netto wrote:
> Hi Carlos,
>
> Updated patch below:
LGTM, but because this is submitted under the existing thread patchwork doesn't
consider this a submission.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> --
>
> From c10d1d59321d3fce0c532304b428dcef3c8cbb3a Mon Sep 17 00:00:00 2001
> From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> Date: Tue, 24 Oct 2023 08:37:14 -0300
> Subject: [PATCH 1/7] powerpc: Do not raise exception traps for
> fesetexcept/fesetexceptflag (BZ 30988)
>
> According to ISO C23 (7.6.4.4), fesetexcept is supposed to set
> floating-point exception flags without raising a trap (unlike
> feraiseexcept, which is supposed to raise a trap if feenableexcept was
> called with the appropriate argument).
>
> This is a side-effect of how we implement the GNU extension
> feenableexcept, where feenableexcept/fesetenv/fesetmode/feupdateenv
> might issue prctl (PR_SET_FPEXC, PR_FP_EXC_PRECISE) depending of the
> argument. And on PR_FP_EXC_PRECISE, setting a floating-point exception
> flag triggers a trap.
>
> To make the both functions follow the C23, fesetexcept and
> fesetexceptflag now fail if the argument may trigger a trap.
>
> The math tests now check for an value different than 0, instead
> of bail out as unsupported for EXCEPTION_SET_FORCES_TRAP.
>
> Checked on powerpc64le-linux-gnu.
> ---
> math/test-fesetexcept-traps.c | 24 ++++++++++++++++--------
> math/test-fexcept-traps.c | 16 +++++++++-------
> sysdeps/powerpc/fpu/fesetexcept.c | 5 +++++
> sysdeps/powerpc/fpu/fsetexcptflg.c | 9 ++++++++-
> 4 files changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/math/test-fesetexcept-traps.c b/math/test-fesetexcept-traps.c
> index 71b6e45b33..7efcd0343a 100644
> --- a/math/test-fesetexcept-traps.c
> +++ b/math/test-fesetexcept-traps.c
> @@ -39,16 +39,24 @@ do_test (void)
> return result;
> }
>
> - if (EXCEPTION_SET_FORCES_TRAP)
> - {
> - puts ("setting exceptions traps, cannot test on this architecture");
> - return 77;
> - }
> - /* Verify fesetexcept does not cause exception traps. */
> + /* Verify fesetexcept does not cause exception traps. For architectures
> + where setting the exception might result in traps the function should
> + return a nonzero value. */
OK.
> ret = fesetexcept (FE_ALL_EXCEPT);
> +
> + _Static_assert (!(EXCEPTION_SET_FORCES_TRAP && !EXCEPTION_TESTS(float)),
> + "EXCEPTION_SET_FORCES_TRAP only makes sense if the "
> + "architecture suports exceptions");
OK. Good _Static_assert to avoid machine misconfiguration.
> +
> if (ret == 0)
> - puts ("fesetexcept (FE_ALL_EXCEPT) succeeded");
> - else
> + {
> + if (EXCEPTION_SET_FORCES_TRAP)
> + {
> + puts ("unexpected fesetexcept success");
> + result = 1;
> + }
> + }
> + else if (!EXCEPTION_SET_FORCES_TRAP)
OK. Tests both sides pass/fail. I like this version.
> {
> puts ("fesetexcept (FE_ALL_EXCEPT) failed");
> if (EXCEPTION_TESTS (float))
> diff --git a/math/test-fexcept-traps.c b/math/test-fexcept-traps.c
> index 9701c3c320..998c241058 100644
> --- a/math/test-fexcept-traps.c
> +++ b/math/test-fexcept-traps.c
> @@ -63,14 +63,16 @@ do_test (void)
> result = 1;
> }
>
> - if (EXCEPTION_SET_FORCES_TRAP)
> - {
> - puts ("setting exceptions traps, cannot test on this architecture");
> - return 77;
> - }
> - /* The test is that this does not cause exception traps. */
> + /* The test is that this does not cause exception traps. For architectures
> + where setting the exception might result in traps the function should
> + return a nonzero value. */
OK.
> ret = fesetexceptflag (&saved, FE_ALL_EXCEPT);
> - if (ret != 0)
> +
> + _Static_assert (!(EXCEPTION_SET_FORCES_TRAP && !EXCEPTION_TESTS(float)),
> + "EXCEPTION_SET_FORCES_TRAP only makes sense if the "
> + "architecture suports exceptions");
OK.
> +
> + if (ret != 0 && !EXCEPTION_SET_FORCES_TRAP)
> {
> puts ("fesetexceptflag failed");
> result = 1;
OK.
> diff --git a/sysdeps/powerpc/fpu/fesetexcept.c b/sysdeps/powerpc/fpu/fesetexcept.c
> index 609a148a95..2850156d3a 100644
> --- a/sysdeps/powerpc/fpu/fesetexcept.c
> +++ b/sysdeps/powerpc/fpu/fesetexcept.c
> @@ -31,6 +31,11 @@ fesetexcept (int excepts)
> & FE_INVALID_SOFTWARE));
> if (n.l != u.l)
> {
> + if (n.l & fenv_exceptions_to_reg (excepts))
> + /* Setting the exception flags may trigger a trap. ISO C 23 § 7.6.4.4
> + does not allow it. */
> + return -1;
> +
> fesetenv_register (n.fenv);
>
> /* Deal with FE_INVALID_SOFTWARE not being implemented on some chips. */
> diff --git a/sysdeps/powerpc/fpu/fsetexcptflg.c b/sysdeps/powerpc/fpu/fsetexcptflg.c
> index 2b22f913c0..6517e8ea03 100644
> --- a/sysdeps/powerpc/fpu/fsetexcptflg.c
> +++ b/sysdeps/powerpc/fpu/fsetexcptflg.c
> @@ -44,7 +44,14 @@ __fesetexceptflag (const fexcept_t *flagp, int excepts)
> This may cause floating-point exceptions if the restored state
> requests it. */
> if (n.l != u.l)
> - fesetenv_register (n.fenv);
> + {
> + if (n.l & fenv_exceptions_to_reg (excepts))
> + /* Setting the exception flags may trigger a trap. ISO C 23 § 7.6.4.4
> + does not allow it. */
> + return -1;
> +
> + fesetenv_register (n.fenv);
> + }
>
> /* Deal with FE_INVALID_SOFTWARE not being implemented on some chips. */
> if (flag & FE_INVALID)
--
Cheers,
Carlos.
next prev parent reply other threads:[~2023-12-19 14:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 13:27 [PATCH v2 0/7] Multiple floating-point environment fixes Adhemerval Zanella
2023-11-06 13:27 ` [PATCH v2 1/7] powerpc: Do not raise exception traps for fesetexcept/fesetexceptflag (BZ 30988) Adhemerval Zanella
2023-11-06 16:08 ` Carlos O'Donell
2023-11-06 16:50 ` Adhemerval Zanella Netto
2023-11-06 17:02 ` Carlos O'Donell
2023-11-06 17:11 ` Adhemerval Zanella Netto
2023-11-06 17:37 ` Adhemerval Zanella Netto
2023-11-06 17:38 ` Carlos O'Donell
2023-11-06 17:56 ` Adhemerval Zanella Netto
2023-11-06 20:46 ` Adhemerval Zanella Netto
2023-11-23 21:47 ` Carlos O'Donell
2023-11-24 12:28 ` Adhemerval Zanella Netto
2023-11-24 12:37 ` Adhemerval Zanella Netto
2023-11-24 16:22 ` Carlos O'Donell
2023-11-24 17:53 ` Adhemerval Zanella Netto
2023-11-24 18:15 ` Carlos O'Donell
2023-11-24 18:46 ` Adhemerval Zanella Netto
2023-11-27 13:46 ` Adhemerval Zanella Netto
2023-12-19 14:57 ` Carlos O'Donell [this message]
2023-11-06 13:27 ` [PATCH v2 2/7] i686: Do not raise exception traps on fesetexcept (BZ 30989) Adhemerval Zanella
2023-11-06 16:14 ` Carlos O'Donell
2023-11-06 13:27 ` [PATCH v2 3/7] x86: Do not raises floating-point exception traps on fesetexceptflag (BZ 30990) Adhemerval Zanella
2023-11-06 16:16 ` Carlos O'Donell
2023-11-06 13:27 ` [PATCH v2 4/7] manual: Clarify undefined behavior of feenableexcept (BZ 31019) Adhemerval Zanella
2023-11-06 16:17 ` Carlos O'Donell
2023-11-06 13:27 ` [PATCH v2 5/7] riscv: Fix feenvupdate with FE_DFL_ENV (BZ 31022) Adhemerval Zanella
2023-11-06 16:19 ` Carlos O'Donell
2023-11-06 13:27 ` [PATCH v2 6/7] alpha: Fix fesetexceptflag (BZ 30998) Adhemerval Zanella
2023-11-06 16:54 ` Carlos O'Donell
2023-11-06 17:36 ` Bruno Haible
2023-11-06 18:15 ` Carlos O'Donell
2023-11-06 13:27 ` [PATCH v2 7/7] hppa: Fix undefined behaviour in feclearexcept (BZ 30983) Adhemerval Zanella
2023-11-06 16:57 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=990d5b9b-b966-fa7e-5fd8-44e1b5902a89@redhat.com \
--to=carlos@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=bruno@clisp.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).