On 05/22/2012 03:19 PM, Lubos Lunak wrote:
On Monday 21 of May 2012, Stephan Bergmann wrote:On 05/21/2012 05:10 PM, Lubos Lunak wrote:On Friday 18 of May 2012, Stephan Bergmann wrote:Ah, you wanted --enable-dbgutil to disable -O2, the same way that --enable-debug does. Had missed that point. Hm, as I said, I prefer my --enable-dbgutil --disable-debug builds to be -O2.What is the point of that combination? As far as I can tell --enable-dbgutil is like --enable-debug but for changes that are BIC, so only dbgutil without debug does not make much sense to me.I rarely use a debugger to step through code, so I prefer to avoid the --enable-debug settings that, AFAIU, are mainly there to aid in step-through debugging, but nevertheless cause potential deviation from a production build (like -O0, -fno-inline).But --enable-debug also enables asserts, logging and similar functionality that should be rather useful for developer builds, doesn't it?
But --enable-dbgutil enables that as well (and more of it).
Turning this around: What is it that you find problematic with --enable-dbgutil not affecting the default -O2?I'm not strongly opposed to it, it just doesn't make much sense to me that way. I see --enable-dbgutil as another, higher, level of --enable-debug, in fact I wonder why it is not simply something like --enable-debug=full. So if you insist, I don't mind that much, but I still don't understand why anyone would want dbgutil without debug (although, on the other hand, dbgutil not affecting e.g. -O2 would not matter much because of this anyway).
So, case closed? Everybody is more or less happy with the status quo of --enable-dbgutil not implicitly affecting default -O2, as far as I understand.
Stephan