At some point, someone is going to have to explain why - despite nobody ever wanting this in production code ever, for any reason - the default CSR state for divide by zero on most platforms is fault instead of flush.
-
Show this thread
-
This is such a tremendous pain in the ass. Most code that has to do an "if this isn't zero, then divide" could be written to "just work" if it could generally assume that the CSRs were always set to flush. But they can't, because it usually isn't.
1 reply 0 retweets 16 likesShow this thread -
Since most numerical code today is in libraries, and libraries can't go setting the CSR because different libraries might conflict, etc., it is really a huge issue. Please someone just change this globally, by fiat. Microsoft? Linux? WASM? PLEASE???
1 reply 0 retweets 13 likesShow this thread -
Maybe somebody has already, and if so, I commend you. But as far as I can tell so far, everybody still defaults to _crashing the program_ when it divides by zero.
2 replies 0 retweets 12 likesShow this thread -
Replying to @cmuratori
Maybe I'm misunderstanding: what would you like the following code to do? int x = 2 / 0; cout << x;
1 reply 0 retweets 0 likes -
Replying to @JaneSchwartz100
It's not what I would like it to do, it's what it _does_ do provided you set MXCSR properly (or the equivalent on other CPUs). With div-by-zero/underflow turned off, and flush-to-zero turned on, 2/0 = 0. So your code would print 0.pic.twitter.com/ju2q6BIfv5
1 reply 0 retweets 1 like -
Replying to @cmuratori @JaneSchwartz100
The only reason it _doesn't_ do that by default is because - for some truly bizarre reason - the default setting for MXCSR is to fault on divide by zero. Even though that is basically never what you want, unless you are debugging.
1 reply 0 retweets 1 like -
Replying to @cmuratori
Shouldn't we want to crash hard with errors like these, instead of letting them go unnoticed silently?
3 replies 0 retweets 2 likes -
Replying to @JaneSchwartz100 @cmuratori
Even for errors, crashing the program is usually a bad way to handle things. But often times it's not an error at all
1 reply 0 retweets 0 likes -
The question is: how often? 90% of the time or 10% of the time? I personally never had case when x/0 was not due to bug in my code.
2 replies 0 retweets 1 like
In _debug_ builds, it should certainly fault, in case you made a mistake. In release builds, it should not, because you can easily write release code where divide by zero produces the correct result.
-
-
Replying to @cmuratori @a_dot_b_dot_ and
My personal preference would be for there to never have been a "fault on divide by zero" in the integer path, I think it is a waste of silicon. Debug builds should simply have inserted jnz/int, and release builds would omit them. This is a far superior solution IMO.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.