On Tue, May 7, 2024 at 10:44 PM Joseph Myers <josmy...@redhat.com> wrote:
>
> On Fri, 3 May 2024, Richard Biener wrote:
>
> > So what I do not necessarily agree with is that we need to preserve
> > the multiplication with -fsignaling-nans. Do we consider a program doing
> >
> > handler() { exit(0); }
> >
> > x = sNaN;
> > ...
> > sigaction(SIGFPE, ... handler)
> > x*x;
> > format_hard_drive();
> >
> > and expecting the program to exit(0) rather than formating the hard-disk
> > to be expecting something the C standard guarantees? And is it enough
> > for the program to enable -fsignaling-nans for this?
> >
> > If so then the first and foremost bug is that 'x*x' doesn't have
> > TREE_SIDE_EFFECTS
> > set and thus we do not preserve it when optimizing __builtin_signbit () of
> > it.
>
> Signaling NaNs don't seem relevant here. "Signal" means "set the
> exception flag" - and 0 * Inf raises the same "invalid" exception flag as
> sNaN * sNaN. Changing flow of control on an exception is outside the
> scope of standard C and requires nonstandard extensions such as
> feenableexcept. (At present -ftrapping-math covers both kinds of
> exception handling - the default setting of a flag, and the nonstandard
> change of flow of control.)
So it's reasonable to require -fnon-call-exceptions (which now enables
-fexceptions) and -fno-delete-dead-exceptions to have GCC preserve
a change of control flow side-effect of x*x? We do not preserve
FP exception bits set by otherwise unused operations, that is, we
do not consider that side-effect to be observable even with
-ftrapping-math. In fact I most uses of flag_trapping_math
are related to a possible control flow side-effect of FP math.
Exact preservation of FP exception flags will likely have to disable
all FP optimization if one considers FE_INEXACT and FE_UNDERFLOW.
Every time I try to make up my mind how to improve the situation for
the user I'm only confusing myself :/
Richard.
> --
> Joseph S. Myers
> josmy...@redhat.com
>
