<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949</a> was mentioned as<br>motivational, but i don't see any resolution there,<br>it's not even in "confirmed" state.</blockquote><div><br></div><div>I agree, this is not at all clear evidence as to GCC's position on the matter.</div></blockquote><div><br></div><div>Sure, but that demonstrates that they are inclined to such interpretation.<br><br>GCC mail list has relevant discussion on this topic: <a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544622.html">https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544622.html</a>. They tried to make the documentation about -ffinite-math-only clearer. The discussion was based on a view that if -ffinite-math-only was specified, a floating point value cannot be NaN or Inf. During the discussion an interesting observation was made:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">… double and double under -ffinite-math-only are different types. Any function call from<br>one world to the other is dangerous. Inline functions translated in different<br>TUs compiled with different math flags violate the ODR.</blockquote><div><br></div><div>If different parts of a program are compiled with and without 

-ffinite-math-only doubles of different flavors can intermix. In the code compiled with -ffast-math a user cannot check assumption about the value by calling "assert(!isnan(x));" because `isnan` is replaced with expected value due to optimizations. The only usable solution in this case could be UBSAN, which is a much heavier solution. <br><br>Two different flavors of double require different mangling. Template specializations also must be different, in particular, specializations of `std::numeric_limits<T>` must be different for these two double types, the methods `has_infinity` and `has_quite_NaN` must return different values.<br><br>They agree that it is profitable to treat NaNs and Infs separately. In this case there would be 4 different double types. It is not clear what to do with constexpr expressions, should the compiler treat using NaN/Inf as undefined behavior even if the ultimate result is finite?<br></div><div><br></div><div>Participants agree that such optimizations are not good:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> … the example of simplifying x * 0 to 0 is about preserving NaNs<br>during expression simplification when the FPU would.  I think these<br>kind of optimizations are what originally was intended to be allowed<br>with -ffinite-math-only - that we started to simplify isnan(x) to false<br>was extending the scope and that change wasn't uncontested since<br>it makes -ffinite-math-only less useful to some people.</blockquote><br>Eventually they came to conclusion:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">… if we want a version of<br>-ffinite-math-only that's well-behaved in language terms (including<br>in terms of the macros that are defined and in the values of<br>numeric_limits), perhaps this should be an official (optional) C/C++<br>extension that defines what the rules are.</blockquote></div><div><br></div><div><div class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--Serge<br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 25, 2021 at 4:25 AM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Aug 24, 2021 at 1:53 PM Roman Lebedev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regardless of everything, i would like to see a patch that restores<br>
the -ffast-math handling, and *then* the RFC on what the is-nan check<br>
should do when -ffast-math is present.<br>
It is more than possible that the RFC will succeed,<br>
but i don't think a change like that should happen the way it did.</blockquote><div><br></div><div>I find the rationale to be convincing, as to the need for a change. But, the scope of the proposal is too narrow. We cannot discuss fast-math semantics changes <i>only</i> for "isnan", it needs to be in the context of the desired behavior for all operations -- the RFC should cover the entire set of changes we want to eventually make, even if isnan is the only thing implemented so far. Discussing this greater scope could result in a different desired implementation, rather than simply adding "llvm.isnan" intrinsic.</div><div><br></div><div>Yet, even with that expanded scope, the two halves of the proposal are still going to be closely linked, so I suspect it still makes sense to discuss both the strict-fp and fast-math changes in a single RFC.</div><div><br></div><div>Anyhow, for the fast-math section, I believe the proposed semantics ought to be:</div><div>  The -ffinite-math-only and -fno-signed-zeros options do not impact the ability to accurately load, store, copy, or pass or return such values from general function calls. They also do not impact any of the "non-computational" and "quiet-computational" IEEE-754 operations, which includes classification functions (fpclassify, signbit, isinf/isnan/etc), sign-modification (copysign, fabs, and negation `-(x)`), as well as the totalorder and totalordermag functions. Those correctly handle NaN, Inf, and signed zeros even when the flags are in effect. These flags <i>do</i> affect the behavior of other expressions and math standard-library calls, as well as comparison operations.</div><div><br></div><div>I would not expect this to have an actual negative impact on the performance benefit of those flags, since the optimization benefits mainly arise from comparisons and the general computation instructions which are unchanged.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949</a> was mentioned as<br>
motivational, but i don't see any resolution there,<br>
it's not even in "confirmed" state.</blockquote><div><br></div><div>I agree, this is not at all clear evidence as to GCC's position on the matter.</div></div></div>
</blockquote></div></div>