This is the mail archive of the
mailing list for the GCC project.
Re: Live range splitting in new allocator
- To: dewar at gnat dot com, torvalds at transmeta dot com
- Subject: Re: Live range splitting in new allocator
- From: dewar at gnat dot com
- Date: Mon, 29 Jan 2001 19:47:34 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org, meissner at cygnus dot com
<<Now _I_ personally think that "-O2 -g" is valid only for trying to find
compiler bugs, and that there might be some other switch for that. But I'm
probably in the minority - everybody else seems to love debuggers to
Well I think Linus *is* in a minority here. Of course -O2 and -g should
work together, and it is unfortunate if they do not, but work is relative,
and in practice, even if you let the register allocator run amok and
generate good code :-) it is quite possible to do some reasonable level
of debugging in -O2 (for instance backtraces are generally still reliable).
It is definitely NOT the case that all bugs can be caught by debugging
at -O0 for at least two reasons.
For really large applications, -O0 generates too much code, and there is
a real difference in debugging a 200 meg exdecutable rather than a
500 meg file. I actually think that a -Og or somesuch, which says "do
all the optimizatoin you can without affecting debuggability" would be
very useful. It might even be the default compilation level for most
people. Gcc takes it a little *too* seriously when you tell it do no
optimization, and looking at the code, you get the feeling that it is
almost as though deliberately bad code is being generated :-)
Second, and more important, in operational large scale systems, it is often
the case that integration problems show up ONLY in the final build at -O2.
For instance, uninitialized variables often cause FAR more trouble at -O2
than at -O0. So if you need to use a debugger to find bugs, as many do, then
you really DO need to be able to use it at -O2.