https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71885
--- Comment #24 from hyc at symas dot com --- (In reply to Manuel López-Ibáñez from comment #21) > (In reply to hyc from comment #19) > > That's all well and good. But, somebody had to go out of their way to > > develop the code to identify this case of new as being a dead store. Why was > > this worth anyone's time to do so? What performance benefit does this > > "optimization" bring, and is it really worth all of the obviously known > > breakage that it causes? > > I don't know the answers to those questions, but somebody did do the effort > to implement it and test it: > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00782.html I see a patch, I don't see justification / motivation / profiling / benchmark results quantifying the impact of this patch. > and then add various options to control it: > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01651.html > > so they probably have their own motivation to do this instead of something > else. Nobody raised any objections at the time. > > > We all have important things to be doing. It doesn't appear that the time > > invested in this "feature" was time well spent. > > For better or worse, we don't get to decide on what other people spent their > own time unless we pay them. No, but you get to decide whether to accept the work or not based on whether it actually solved a problem that programmers care about. Or whether the added complexity was worth any added maintenance cost or compile time. This feature is enabled at -O1, which is usually reserved for non-aggressive, benign optimizations. In what way is this feature an optimization? How does it qualify as benign? Where was *any* critical review of this thing? When I was a gcc maintainer (1988-1996) a patch like this wouldn't have proceeded without answers to these questions.
