| Message ID | 20231103122416.2724355-5-adhemerval.zanella@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Multiple floating-point environment fixes | expand |
On Fri, 3 Nov 2023, Adhemerval Zanella wrote: > +Note: Enabling traps for an exception for which the exception flag is > +currently already set (@pxref{Status bit operations}) has undefined > +consequences: it may or may not trigger a trap immediately. I think we should say "unspecified", not "undefined" (in the manual and commit message). It might trap immediately, on a future floating-point instruction or not at all, but there shouldn't be any other possibilities; it's not undefined behavior.
Joseph Myers wrote: > I think we should say "unspecified", not "undefined" (in the manual and > commit message). I agree. Thanks Joseph for the more precise wording. Bruno
On 05/11/23 21:17, Bruno Haible wrote: > Joseph Myers wrote: >> I think we should say "unspecified", not "undefined" (in the manual and >> commit message). > > I agree. Thanks Joseph for the more precise wording. > > Bruno Ack.
diff --git a/manual/arith.texi b/manual/arith.texi index fa7110e992..68c6446a5b 100644 --- a/manual/arith.texi +++ b/manual/arith.texi @@ -1176,6 +1176,12 @@ enabled, the status of the other exceptions is not changed. The function returns the previous enabled exceptions in case the operation was successful, @code{-1} otherwise. + +Note: Enabling traps for an exception for which the exception flag is +currently already set (@pxref{Status bit operations}) has undefined +consequences: it may or may not trigger a trap immediately. +@c It triggers a trap immediately on powerpc*, at the next floating- +@c instruction on i386, and not at all on the other CPUs. @end deftypefun @deftypefun int fedisableexcept (int @var{excepts})
From: Bruno Haible <bruno@clisp.org> * manual/arith.texi (Control Functions): Explain undefined behavior of feenableexcept in a special case. --- manual/arith.texi | 6 ++++++ 1 file changed, 6 insertions(+)