On 2012-04-05 15:09:32 +0200, Erik Trulsson wrote: > Better would be to improve the output from -O1 so it is usable by a > debugger, even if this might require generating slightly less optimized > code at -O1 than is done now.
This contradicts what you say below. > > > What is missing to me is a reasonable cleanup of the code that > > > would remove some of the junk at -O0 but not impact debugging. > > > In fact a reasonable criterion would be all the optimization > > > that is cheap to do and does not affect debugging. > > > > I think that for debugging, there should be a single option to > > disable optimizations that are unsafe for the debugger and that > > would add debugging information (such as what -g does). In short, > > the user would just have to add this option, which should do all > > the magic for debugging. > > No, absolutely not. Turning on debugging should not change what the > generated code looks like. For instance, the effect of a bug appears only with -O3. Then you have 2 possibilities: 1. The debugger can cope with such optimization levels. So, -O1 doesn't need to be modified. 2. The debugger cannot cope with such optimization levels, and you are forced anyway to change what the generated code looks like in order to try to debug it (or improve the debugger to be in case 1, if possible). > Depending on the bug it is quite possible for changes in > optimization to hide the symptoms of the bug, thereby making it more > difficult to track down the bug. I agree, but this is not by removing some default optimizations that you would solve the problems due to a bug that appears when the user chooses to use a higher optimization level. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
