2 ms·
Only up to a point. This bug is a misfiring attempt at detecting undefined behavior to allow for optimizations. If we did not attempt to remove null pointer che
by rocqua 7y ago
Only up to a point. This bug is a misfiring attempt at detecting undefined behavior to allow for optimizations.
If we did not attempt to remove null pointer checks, that would have prevented this bug in GCC.
Hence, the practice of optimizing based on UB is relevant here, even if this was a compiler bug, rather than a compiler optimizing based on UB.
- saagarjha 7y ago> This bug is a misfiring attempt at detecting undefined behavior to allow for optimizations. I don't think it is. It's the same as removing the conditional here: int foo = 1; if (foo) { // whatever } The compiler (incorrectly) deduced that the pointer was non-NULL and removed the check because it saw it as unnecessary.
- jcranmer 7y ago> This bug is a misfiring attempt at detecting undefined behavior to allow for optimizations. It's closer to a conditional constant propagation that was accidentally applied unconditionally. The code was guarded by an if statement that asserted that a variable did not have a particular value, which lets the compiler delete further checks that the variable does or does not have the value. No UB behavior in play, unless you're complaining about the UB of "variables can't be changed unless the programmer changes them directly or indirectly." If you pay attention to the change that introduced the bug--it was a change in the constant propagator that caused the bug.