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: Mon, 6 Nov 2023 12:02:37 -0500 [thread overview]
Message-ID: <6e4ff3c5-8504-79a4-8865-0239b0cd7185@redhat.com> (raw)
In-Reply-To: <5e031d35-5d3e-49a7-b354-809bb4a1dc8f@linaro.org>
On 11/6/23 11:50, Adhemerval Zanella Netto wrote:
>
>
> On 06/11/23 13:08, Carlos O'Donell wrote:
>> On 11/6/23 08:27, Adhemerval Zanella wrote:
>>> 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.
>>
>> OK. I reviewed ISO C 2x (n3096), and I agree this is permissible and preferable.
>>
>>>
>>> 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.
>>
>> Changes test from UNSUPPORTED to PASS when we should test more now that with
>> C2x we're saying the behaviour will result in a non-zero return... then we
>> should test for that.
>>
>>> ---
>>> math/test-fesetexcept-traps.c | 11 ++++-------
>>> math/test-fexcept-traps.c | 11 ++++-------
>>> sysdeps/powerpc/fpu/fesetexcept.c | 5 +++++
>>> sysdeps/powerpc/fpu/fsetexcptflg.c | 9 ++++++++-
>>> 4 files changed, 21 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/math/test-fesetexcept-traps.c b/math/test-fesetexcept-traps.c
>>> index 71b6e45b33..96f6c4752f 100644
>>> --- a/math/test-fesetexcept-traps.c
>>> +++ b/math/test-fesetexcept-traps.c
>>> @@ -39,16 +39,13 @@ 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. */
>>> ret = fesetexcept (FE_ALL_EXCEPT);
>>> if (ret == 0)
>>
>> We can check for a non-zero return if EXCEPTION_SET_FORCES_TRAP?
>>
>> e.g.
>>
>> if (!EXCEPTION_SET_FORCES_TRAP)
>> {
>> if (ret == 0)
>> puts ("fesetexcept (FE_ALL_EXCEPT) succeeded");
>> else
>> /* fail */
>> }
>> else
>> {
>> if (ret == 0)
>> /* fail */
>> else
>> /* pass */
>> }
>
> The '!EXCEPTION_SET_FORCES_TRAP && ret == 0' or 'EXCEPTION_SET_FORCES_TRAP && ret == 1'
> checks are not really meaningful: either the function succeeds and return 0, or it fails
> for some reason. And for failure, EXCEPTION_SET_FORCES_TRAP really means an expected
> failure.
Sure.
> So if the function succeeds and no trap is generated (which terminates the process
> as default on Linux) we are fine. Otherwise, it check if the failure is expected
> (EXCEPTION_SET_FORCES_TRAP).
>
So we go from UNSUPPORTED to... ?
--
Cheers,
Carlos.
next prev parent reply other threads:[~2023-11-06 17:02 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 [this message]
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
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=6e4ff3c5-8504-79a4-8865-0239b0cd7185@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).