<p dir="ltr">IEEE standard specify infinities as distinguished from NAN.  Not that the IEEE standard always makes the best choices (semantics of min and max being the naughtiest ). But to the extent that hardware supoorts toggling what values trigger failure it should be reasonably toggle -able </p>
<p dir="ltr">For Intel hardware I'll presume only hardware that has sse2 and newer, and maybe a warm-up or sibling patch would be to excise x87 float support from the code gen in GHC <br></p>
<p dir="ltr">Amusingly one intended use for the large space of nan values was to encode the nature of the computation that created the nan.  And this was intended to be used by language implementors.  Not sure if that will be useful. </p>
<p dir="ltr">Anyways, this and the other positive response is encouraging and I'll see about making the time to dig into this stuff. </p>
<p dir="ltr">Merry friday all!<br>
-Carter</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 16, 2016 11:40 AM, "Ben Gamari" <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> writes:<br>
<br>
> Hello All!<br>
> I had some interesting conversations yesterday with a few folks and the<br>
> take away was that I might experiment with adding an off by default rts<br>
> flag that on applicable architectures that makes all floating point<br>
> computations that yield Nans signaling , plus mayve some HS side hooks to<br>
> enable or disable that per green thread if it doesn't harm no fib.  Kinda<br>
> like the way green threads track and save / restore the state of the magic<br>
> c error tracking variable<br>
><br>
</div>Sounds reasonable to me; debugging floating point issues is certainly a<br>
chore and this could only help. Regarding a per-thread handling I think<br>
we'd certainly need to benchmark. Note that rts/posix/Signals.c already has<br>
some logic to handle SIGFPE, although it has been disabled for over a<br>
decade due to an infinite loop where the handler immediately threw<br>
another FPE. It would be nice to have a solution to this issue; looping<br>
is quite bad.<br>
<br>
Do you lump infinities into the class of NaN values? I'm not sure how<br>
much code would fail due to "legitimate" uses of infinity if so.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div><br></div>