https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Sep 2021, gabravier at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
> 
> Gabriel Ravier <gabravier at gmail dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |gabravier at gmail dot com
> 
> --- Comment #5 from Gabriel Ravier <gabravier at gmail dot com> ---
> Also of note should be the fact that Clang's current default is
> `-fno-trapping-math`.
> 
> I'm myself kind of curious about how exactly `-ftrapping-math` is interpreted.
> It certainly doesn't seem to remove every single kind of non-trapping
> math-based optimization: GCC will remove such statements as `(void)1/x;` even
> with `-ftrapping-math`, even though that could fault with `x == 0`, and will
> optimize things like `float x = 3412897421;` to not do a conversion even 
> though
> that conversion could raise an exception (as 3412897421 cannot be exactly
> represented as a float), whereas Clang won't do that kind of optimization and
> will keep those operations as-is.

Yes, as said in other contexts GCC happily _removes_ traps if trapping
is the only side-effect.  _Unless_ you also have -fnon-call-exceptions
enabled which is the only way to observe traps.  So we consider
a trap invoking undefined behavior unless you make them well-defined
via -fnon-call-exceptions.

I suppose that argues for a tighter coupling of -fnon-call-exceptions
and -ftrapping-math and in particular not enabling -ftrapping-math
by default (unless -fnon-call-exceptions is enabled?).

Btw, the issue also repeatedly comes up in the context of -ftrapv.

I guess I'll propose a documentation enhancement where we can then
discuss the best way forward.

Note that options like -ftrapv and -ftrapping-math also make GCC
avoid transforms that may turn expressions that do not trap into
expressions that do.  For both that is re-association which can
lead to intermediate integer overflows and intermediate inexact
exception traps.

Reply via email to