Weekly Edition
Return to the Development page
| |||||||||||||
GCC 4.5.0 released
GCC 4.5.0 has been released. The changes page has the
details. Support has been added or enhanced for a number architectures
such as ARM, IA-32/x86-64, M68K/ColdFire, MeP, MIPS, RS/6000
(POWER/PowerPC), and RX. There are plenty of language specific
improvements and general optimizer improvements as well.
(Log in to post comments)
GCC 4.5.0 released Posted Apr 15, 2010 18:42 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Awesome! I had wondered for a second when I saw the 4.5.0 manuals up yesterday, but I figured it was because it was close (but didn't realize it was *that* close!)
Congrats to the GCC team!
GCC 4.5.0 released Posted Apr 15, 2010 18:56 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
The gcc 4.5 release notes neglect to brag about the debugging information improvements associated with the Variable-Tracking-Assignments code, which makes optimized code more debuggable than before.
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
GCC 4.5.0 released Posted Apr 18, 2010 11:09 UTC (Sun) by makomk (guest, #51493) [Link]
Ah good. I've been having real problems running gdb usefully on code compiled by gcc 4.4 at anything above -O0; hopefully this will make my life easier. (Previous gcc versions weren't so bad - most stuff was just about doable at -O2 and nearly everything worked at -O1.)
GCC 4.5.0 released Posted Apr 15, 2010 19:03 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] You didn't mention plugins, which is going to have a huge impact. New capabilities, new things to flame about, since now that so many new things can be done, people will argue about whether they should be done.
GCC 4.5.0 released Posted Apr 15, 2010 19:37 UTC (Thu) by asdfasdfasdf (guest, #63578) [Link]
Too bad LLVM DragonEgg isn't included in this release.
GCC 4.5.0 released Posted Apr 15, 2010 19:58 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, inclusion was only suggested a few days ago, deep into the prerelease freeze. So it would never have been included, even if both uncontroversial and the best thing in the whole world.
GCC 4.5.0 released Posted Apr 15, 2010 23:10 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The thing about the plugin architecture is that something like DragonEgg doesn't need to be included in the release; it plugs in. There was a technical argument about whether gcc should add a patch to make DragonEgg work out of the box or whether DragonEgg should be modified to use the API properly, but that kind of thing can be worked out; the issue came up too late in the release cycle to be cleanly resolved yet.Plugins avoid (or at least reduce) the complexity of worrying about legalities and assignments to the FSF and debates about what should go in or not. One thing I would hope to avoid in these discussions is gcc vs llvm flaming, KDE/Gnome style. Generally speaking the developers are on good terms and respect each other, and good ideas move back and forth. But sometimes you get a fanboy phenomenon, with non-developers cheering on one and flaming the other.
GCC 4.5.0 released Posted Apr 16, 2010 10:39 UTC (Fri) by nix (subscriber, #2304) [Link] Generally speaking the developers are on good terms and respect each other, and good ideas move back and forth.How could they not? A good few of them are the same people!
Win64 Posted Apr 15, 2010 21:48 UTC (Thu) by proski (subscriber, #104) [Link] Does anyone knows the status of Win64 support? LLP64 is ugly, but Win64 is here to stay. It could be another advantage of free software if it could deliver 64-bit binaries for Windows platform (such as Firefox, OpenOffice.org, GIMP, KDE) whereas non-free software is slow to adopt Win64.
Win64 Posted Apr 16, 2010 0:31 UTC (Fri) by dicej (guest, #36115) [Link]
I've been building cross-compilers with --target=x86_64-w64-mingw32 from GCC 4.5 snapshots for months now without any trouble. The mingw-w64 project (http://mingw-w64.sourceforge.net/) provides a complete build environment including GCC, binutils, system headers, etc., and there are many projects using it already.
Win64 Posted Apr 16, 2010 10:42 UTC (Fri) by nix (subscriber, #2304) [Link]
LLP64 is downright normal compared to some of the things GCC has had to deal with in the past. It has no real trouble with it.
Win64 Posted Apr 16, 2010 11:13 UTC (Fri) by mstefani (subscriber, #31644) [Link]
As others have said Win64 works for a while now (since 4.4.0). But 4.5.0 introduced a regression; sadly that regression was detected only shortly before the 4.5.0 release.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
GCC 4.5 official release announcement Posted Apr 19, 2010 8:20 UTC (Mon) by mjw (subscriber, #16740) [Link]
It has now been officially released, with a release announcement:
http://gcc.gnu.org/ml/gcc-announce/2010/msg00001.html
The Free Software Foundation and the GNU Compiler Collection (GCC)
|
|||||||||||||