GCC 4.5.0 released [LWN.net]

Debugging optimized

Posted Apr 15, 2010 21:48 UTC (Thu) by ncm (subscriber, #165) [Link]

This is important news, if only because many important warnings only show up when compiling optimized. If you usually build unoptimized during development just so you can use the debugger without getting lost, and therefore miss those warnings, maybe you can change now.

(The announcement reminds me that it's been a long time since I had to debug a problem resulting from optimized code behaving differently from the unoptimized. Congratulations to a lot of somebodies, on both counts.)

Almost equally as valuable as the noted improvement would be an ability to compile as if maximally optimizing, and actually emitting all attendant warnings, but writing out unoptimized, maximally debuggable code.

Debugging optimized

Posted Apr 15, 2010 23:46 UTC (Thu) by jreiser (subscriber, #11027) [Link]

... an ability to compile as if maximally optimizing, and actually emitting all attendant warnings, but writing out unoptimized, maximally debuggable code.

What more than: gcc -O3 -c foo.c && gcc -g -O0 -c foo.c >/dev/null 2>&1 ?

Debugging optimized

Posted Apr 16, 2010 9:21 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>What more than [...]?

-Wall, for one. -ggdb3, for another. And for completeness, -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes.

Debugging optimized

Posted Apr 16, 2010 16:28 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Oy... The redundant declarations one is maybe a bit annoying. :-) Otherwise, I use these other flags as well:

-Wall -W -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wc++-compat

Now if flex-generated code didn't cause so many warnings. The only warnings in my own "major" app, jzIntv, come from code I didn't write:

bincfg/bincfg_lex.c: In function yy_get_next_buffer:
bincfg/bincfg_lex.c:1858: warning: comparison between signed and unsigned
bincfg/bincfg_lex.c: At top level:
bincfg/bincfg_lex.c:2413: warning: no previous prototype for bc_get_lineno
bincfg/bincfg_lex.c:2422: warning: no previous prototype for bc_get_in
bincfg/bincfg_lex.c:2430: warning: no previous prototype for bc_get_out
bincfg/bincfg_lex.c:2438: warning: no previous prototype for bc_get_leng
bincfg/bincfg_lex.c:2447: warning: no previous prototype for bc_get_text
bincfg/bincfg_lex.c:2456: warning: no previous prototype for bc_set_lineno
bincfg/bincfg_lex.c:2468: warning: no previous prototype for bc_set_in
bincfg/bincfg_lex.c:2473: warning: no previous prototype for bc_set_out
bincfg/bincfg_lex.c:2478: warning: no previous prototype for bc_get_debug
bincfg/bincfg_lex.c:2483: warning: no previous prototype for bc_set_debug
bincfg/bincfg_lex.c:2517: warning: no previous prototype for bc_lex_destroy

*sigh* I have a severe allergy to tweaking generated code.

Debugging optimized

Posted Apr 16, 2010 10:40 UTC (Fri) by nix (subscriber, #2304) [Link]

That does the work twice. We *already* have LTO doing the work twice: add this, and we'd be doing the work four times over (or we would do once LTO and debugging information play well together).

This feels a right waste to me.

Debugging optimized

Posted Jul 4, 2010 21:45 UTC (Sun) by oak (subscriber, #2786) [Link]

And the fix to the bogus warnings GCC gave e.g. about code in if or case clause accessing array elements that the if/case specifically protects against:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902