On Nov 24, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: >> Yes, catching all such cases hasn't been trivial. If we miss some, >> then what happens is that -O2 -g -fvar-tracking-assignments outputs >> different executable code than -O2.
> But that's a very serious type of bug because it means you have > situations where a program fails and you can't debug it because when > you turn on debugging information, it doesn't fail anymore. We need > to make an absolute rule that this *cannot* happen and luckily this is > one of the easiest types of errors to project against. I agree completely. That's why I've gone to such great lengths to ensure these errors are easily testable in my implementation, and to put all my changes under control of a command-line option. Then, you can still get (poorer) debug information by disabling (or not enabling) this option. And then, despite the consensus that GCC must not generate different code with and without -g, the patch that fixes one such regression has been lingering for months, and the patch that introduced the regression hasn't been reverted either. Besides, the Ada RTS compiles differently with -g than without -g, such that compare-debug doesn't pass if you compare sysdep.o. Nobody but me seems to care. I'm sure I'm going to find other differences between -g and -g0 once I fix this and bootstrap4-debug gets past this point and builds other target libraries. I'm not looking forward to the discussions that will ensue if any fixes for these problems imply any costs whatsoever, given the experience I've had with the SSA-coalescing and the optimize-basic-blocks issues that are all about debug information versus optimization :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
