Slashdot Mirror


GCC 3.4.0 Released

AaronW writes "While checking the GCC website I saw that GCC version 3.4 was officially released on April 18th. Version 3.4 includes numerous changes and enhancements, including better optimization, and the ability to build a profiled version of gcc which is 7.5-11% faster on i386 hardware. Be kind and please use one of the mirror sites."

68 comments

  1. Not officially released yet by RML · · Score: 5, Informative

    This announcement is premature, it's still propagating to mirrors; the "announcment" is an error. The official release will be tomorrow.

    --
    Human/Ranger/Zangband
  2. pch by rmull · · Score: 2

    Yes! Precompiled headers will be miiiiiiiiine!!!!!

    --
    See you, space cowboy...
    1. Re:pch by 0x0d0a · · Score: 3, Informative

      For those not familiar with precompiled headers, you can basically look forward to *much* faster code compilation, especially with C++.

      Precompiled headers are disabled by default in this release.

    2. Re:pch by Crayon+Kid · · Score: 1

      There's already ccache which does a great job of speeding up second time compilations. Yeah I know there are all kinds of differences between this and precompiled headers, I was just pointing out another build speedup method.

      --
      i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
  3. new feature by Tumbleweed · · Score: 4, Funny

    "precompiled announcements"

  4. but who by mithras+the+prophet · · Score: 4, Funny

    is still using a 386 anymore??? Get with the times, gcc! ;)

    --
    four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
    1. Re:but who by Anonymous Coward · · Score: 0, Insightful

      In case you aren't joking:

      i386 architecture != 386 cpu

  5. Ideally... by me98411 · · Score: 5, Funny

    Ideally no one would have noticed until tomorrow, when the official announcement will go out..

    They did not think about /., did they?

  6. Bit Torrent by Anonymous Coward · · Score: 0

    I thought this problem was solved by Bit Torrent. It's worked well for other projects.

  7. Profiling shared libraries by wowbagger · · Score: 4, Interesting

    Has the ability to profile shared libraries been fixed? I have tried to do this, and even if you compile a shared library with -pg, and specify it in the LD_PROFILE environment variable, the resulting profile file cannot be processed by gprof V2.4 - instead you get "error: unsupported profile revision 131,071"

    I *really* need to profile a shared library, and building it as a staticly linked executable is not an option.

    1. Re:Profiling shared libraries by prat393 · · Score: 1

      What version is 2.4, exactly? My gprof returns the same version as the binutils installed, 2.14.etc. Certainly profile feedback works, but I'm fairly sure that's not what you mean. Maybe you want to do something with gcov?

    2. Re:Profiling shared libraries by wowbagger · · Score: 2, Informative

      My bad - there is a seperate program, sprof, that you use to profile the data from shared libraries.

      Of course, gprof doesn't mention sprof in the manual, info pages, or in the error message, nor is it mentioned in any of the web pages about this subject.

  8. GCJ by InsaneCreator · · Score: 3, Interesting

    Could someone explain how well does the gcj Java compiler work? I hear that AWT and Swing are not really usable, so how well does it work with SWT or maybe even wxWidgets?

    I'm currently in the process of choosing the language/tools for a cross platform app (open source, of course) and I've narrowed the selection down to Java+gcj and c++. Native executables & widgets are a must, since my target audince most likely won't have a JVM installed.

    1. Re:GCJ by thufir · · Score: 3, Informative

      It works nicely with SWT.

      Take the fact that redhat compiled eclipse itself using gcj. You can get the RPM off their website somewhere.

    2. Re:GCJ by pnatural · · Score: 1

      You can get that here:

      Natively Compiled Eclipse

    3. Re:GCJ by rmathew · · Score: 4, Informative
      Swing/AWT using Gtk+ peers has been making tremendous progress in the last few months thanks to a bunch of Red Hat hackers and is quite usable as can be seen here for example.

      Unfortunately, these changes are not a part of the 3.4.0 release of GCC/GCJ and will only be available from 3.5.0 (or 4.0.0, as the case might be).

    4. Re:GCJ by XiC · · Score: 3, Informative

      It works like a charm for me using swt on windows.

      Have a look at http://www.thisiscool.com/gcc_mingw.htm for the windows version.

      Also the java application still works as a java application using Linux and MacOSX (still using swt).

  9. WTF? by Anonymous Coward · · Score: 0, Funny

    1) No download link
    2) No Windows installer
    3) No articles on new features except some skimpy list
    4) No code samples
    5) No comparisons between what the old version generated and what the new one does (with C++ examples)

    I am sticking to Microsoft Visual C++, free version, that was recently announced here. More optimization options, too.

    1. Re:WTF? by j-pimp · · Score: 0, Flamebait

      2) No Windows installer
      The windows port is released seperatly by mingw and cygnus folks. But if you want lonks all I can offer you is a link to a REAL(tm) compiler, Open Watcom.
      And for all you linux zealots out their reading slashdot with Internet Explorer, their working on the linux version. I believe they even hired some indians to help with the port. Thats sure to start a flame war on slashdot, offshore outsourcing to do open source programming.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    2. Re:WTF? by jhunsake · · Score: 5, Funny

      6) No screenshots

    3. Re:WTF? by Tagren · · Score: 1
      It is not that... colorfull stuff around it but:
      http://freshmeat.net/screenshots/3088/
    4. Re:WTF? by cant_get_a_good_nick · · Score: 1

      http://www.mindspring.com/~jamoyers/software/color gcc/colorgcc.gif
      sorry for any Lameness filter breakage

    5. Re:WTF? by EugeneK · · Score: 1
  10. Thanks by Markus+Registrada · · Score: 4, Informative
    I don't know about the other bundled compilers, but the 3.4 C++ compiler and library are the best ever in Gcc, by far.

    If you run across them, be sure to thank Paolo Carlini, Petur Runolfsson, and Jerry Quinn for making 3.4 iostreams as fast as (and often faster than) Glibc's stdio. Thank them, too for making filebuf support large files (>2G) natively without any code or build changes needed, on any target that allows them.

    Worth noting, too, is that this is the first release in which the library is part of the ABI. Every previous release since 2.95 has had to increment the libstdc++.so version number, but future 3.4 (and maybe 3.5) releases should be backward compatible. Ask your distribution maintainers to ship 3.4-built versions of all C++ libraries they package, so that they will be compatible with programs built with this and future releases.

    1. Re:Thanks by Anonymous Coward · · Score: 0

      i call bullshit

      how, pray tell, do iostream's go faster than glibc's fstreams, when the iostreams ultimately _call_ the f*() functions?

    2. Re:Thanks by Euphonious+Coward · · Score: 3, Informative
      how ... do iostream's go faster than glibc's fstreams, when the iostreams ultimately _call_ the f*() functions?

      Simple: they don't. They call read() and write(), and do their own buffering. Even if they did use fread() and fwrite(), they would still be able to do their their own per-character buffering, and their own numeric formatting and parsing, and thus be faster.

      p.s. I call "Troll".

  11. Broken C++ ABI ... again by Lumpish+Scholar · · Score: 4, Informative

    They broke binary compatibility in gcc 3.0, and again in 3.2, and now in 3.4.

    What do you think the outlook is for binary compatibility with 3.6?

    --
    Stupid job ads, weird spam, occasional insight at
    1. Re:Broken C++ ABI ... again by Anonymous Coward · · Score: 0
      They broke binary compatibility in gcc 3.0, and again in 3.2, and now in 3.4.

      Who gives a shit about Sparc binary compatibility?

    2. Re:Broken C++ ABI ... again by prat393 · · Score: 1

      The sparc people who have to recompile every c++ program on their system might care, just offhand. And since you asked (or didn't), i386 users will probably care, too - their ABI changed as well.

    3. Re:Broken C++ ABI ... again by Dr.Dubious+DDQ · · Score: 4, Interesting

      Well, if you want to be technical about it, it's not "Broken" C++ ABI, but a "Finally fixed, even though that makes it no longer bug-for-bug compatible with older GCC C++ ABI's"...

      As I understand it, they've been working towards a more standards compliant C++ implementation, and that's why the binary compatibility gets lost.

      I am, though, hoping that there was NOT a loss of compatibility between the 3.3.3 that I'm using now and the 3.4 series. Will find out once I clean off enough disk space to finish compiling up slack packages for myself...

    4. Re:Broken C++ ABI ... again by Anonymous Coward · · Score: 0
      The sparc people who have to recompile every c++ program on their system might care, just offhand.

      Yeah, the hundred or so SPARC/MIPS users who 1) compulsively upgrade their toolchain, and 2) need to compile against C++ libs will be inconvenienced... But they're probably used to it by now, after all the previous C++ ABI changes.

      i386 users will probably care, too - their ABI changed as well

      I haven't seen that mentioned anywhere.

    5. Re:Broken C++ ABI ... again by turgid · · Score: 2, Informative
      I haven't seen that mentioned anywhere.

      So go and read this very carefully:

      The C++ ABI Section 3.3.3 specifications for the array construction routines __cxa_vec_new2 and __cxa_vec_new3 were changed to return NULL when the allocator argument returns NULL. These changes are incorporated into the libstdc++ runtime library.

    6. Re:Broken C++ ABI ... again by Lumpish+Scholar · · Score: 1
      Well, if you want to be technical about it, it's not "Broken" C++ ABI, but a "Finally fixed, even though that makes it no longer bug-for-bug compatible with older GCC C++ ABI's"...
      Granted.
      As I understand it, they've been working towards a more standards compliant C++ implementation, and that's why the binary compatibility gets lost.
      I understand they do it reluctantly, and only with good reason. I'm just depressed at how often it's happened.
      I am, though, hoping that there was NOT a loss of compatibility between the 3.3.3 that I'm using now and the 3.4 series.
      Since none of the 3.3.x change logs have said anything to this effect, and since the gcc guys like to only break compatibility at fairly major release points, I think you're in the same boat I'm in. Care for a bailing bucket?
      --
      Stupid job ads, weird spam, occasional insight at
    7. Re:Broken C++ ABI ... again by elflord · · Score: 1
      So go and read this very carefully:

      How does that affect binary compatibility ? This should only affect out-of-memory conditions which usually result in program termination anyway, right ?

    8. Re:Broken C++ ABI ... again by turgid · · Score: 1
      How does that affect binary compatibility ?

      The aliens came down in their flying-saucer one night and told me so so it must be true :-)

  12. GCJ with Java+QT by bcore · · Score: 3, Informative

    FWIW: I have done some app development on Linux using Java compiled with GCJ with UI provided by QT (through the KDEBindings package). I found it worked quite well, and the app was very responsive (didn't feel nearly as clunky as Swing apps often do).

    My only complaint was that the occasional completely random feature seemed not to work, as though they had missed a few bindings.. I can't think of any examples, but it was nothing serious.

  13. That's who by fm6 · · Score: 2, Insightful

    Well, these guys, these guys, and these guys seem to have no trouble selling 386-based hardware. Not everybody needs the full feature set (or the cost and power requirements) of a Pentium.

  14. PCH and auto* by greppling · · Score: 2, Interesting

    Has anybody done the work to setup PCH in a project built with the standard GNU Makefile tools autoconf/make/header? I tried it once, but didn't see a good solution to get the dependencies right. Of course, genuine support for it by automake would be great.

  15. My thoughts and ramblings by Arngautr · · Score: 1

    What does a gentoo user do if new versions of apps they use come out? They recompile those apps, so I was wondering do they recompile lots of stuff when a new gcc comes out? On another note I notice Ada is getting some attention, do the added features mean it's not super standard, and thus becoming more C++ like? And does the improved confmity to standards of G++ mean C++ is becoming more Ada like? One thing that bugs me about C++ are the extra ';' at the end of some brackets, though I know at least one reason to include them, but now I can't throw in useless ';' after all my brackets, only some, where they are required? Also the Ada improvements include " Additional set of warnings about potential wrong code Improved error messages Improved code generation" , but does c++?(answer for those who Don't RTFAs: NO) :), I'm actually starting to understand their error messages, but sometimes when a friend asks me to help with their coding problems I have no clue (template >) --Ghaaa. What's this world coming to when I can't even accept my own friend's typedefs? One can't legislate good form!!!!!...oh wait you did "This is actually ill-formed and it is now rejected" It also seems they ditched yacc and that's no bison!

  16. Eclipse running out of the box on GIJ ! by Anonymous Coward · · Score: 0

    They say that Eclipse now runs out of the box on GIJ ! The GCC people rock big time ! :)

  17. Idle curiosity by bhima · · Score: 2, Interesting

    OK I know this is just idle curiosity but I think a general comparison between Microsoft's new offering, Borland's Free command line tools, Open Watcom and GCC might be interesting.

    --
    Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
    1. Re:Idle curiosity by Anonymous Coward · · Score: 0

      I think a general comparison between Microsoft's new offering, Borland's Free command line tools, Open Watcom and GCC might be interesting.

      So it might. Which GCC did you have in mind? Cygwin? MinGW?

    2. Re:Idle curiosity by CoolGuySteve · · Score: 2, Interesting

      Don't forget ICC. If GCC could even begin to compete somewhat with the Intel compilers, the scientific community would probably take notice. From the experiences of the programmers and students at our department, Intel stuff is really buggy and wastes a lot of time with things like 'Internal Compiler Errors' and examples in the documentation that either don't work or don't compile.

      Maybe IFC and ICC work better if you're not doing anything complicated or using exotic hardware, they probably weren't tested much on Itanium systems with 64GB of ram.

    3. Re:Idle curiosity by arkanes · · Score: 3, Informative
      From my experience:

      MS "new" compiler compiles fast, optimizes well for both size and speed, and is very standards compliant.
      BCC compiles very fast, optimizes well for size and speed, and is poorly standards compliant.
      OpenWatcom is similiar to BCC
      GCC (in the form of MingW) compiles slowly, optimizes well for speed but (very) poorly for size, and is very standards compliant.

      Of the free beer options, on Windows, MS C++ 7.1 is the all-round winner imo. GCC/MingW is a very close second, however, with the main issues being much slower compile time (partially correctable via things like ccache, and the new pch support should help) and signifigantly larger binaries. In terms of standards compliance they're about equal, with GCC taking a slight lead.

    4. Re:Idle curiosity by Anonymous Coward · · Score: 0

      If you want small binaries in C++ using mingw, you should avoid the use of iostreams. As soon as you add these, the size balloons. This doesn't apply for all of the standard library, just the streams, so its possible to get by without them.

    5. Re:Idle curiosity by Darth+Yoshi · · Score: 1
      I don't get it. First you say:
      Don't forget ICC. If GCC could even begin to compete somewhat with the Intel compilers, the scientific community would probably take notice.

      Then you say.
      From the experiences of the programmers and students at our department, Intel stuff is really buggy and wastes a lot of time with things like 'Internal Compiler Errors' and examples in the documentation that either don't work or don't compile.

      Are you suggesting that GCC should be buggier so it can compete with ICC?
      --
      // TODO: fix sig
  18. This may be a stupid question, but... by Anonymous Coward · · Score: 1, Interesting

    ...where does one get the PGP/GPG public key necessary to validate the gcc-3.4.0.tar.bz2.sig file? I've searched all over the gcc.gnu.org website and I cannot find it.

    1. Re:This may be a stupid question, but... by Anonymous Coward · · Score: 0

      pgpdump shows a key ID of 0x93FA9B1AB75C61B8. "gpg --recv-keys 0xB75C61B8" worked for me (using pgp.mit.edu as my keyserver). The name on the key is "Mark Mitchell ".

  19. Really nice on Itanium systems by Anonymous Coward · · Score: 0

    3.4 builds code about 50% faster than 3.3 on Itanium systems (I mean it actually compiles 50% faster, not that the programs that come out are 50% faster.. for that, still gotta use the Intel, Microsoft, HP or Open64/OpenIMPACT compilers..)

    Still, I run gentoo, this will really cut down the time spent updating non performance-critical bits of code!

    1. Re:Really nice on Itanium systems by Anonymous Coward · · Score: 0

      For Itanic? You have to use Intel's compiler. MSVC's Itanium backend is just as shitty as GCC's. Haven't used HP's though.

  20. Sorry - typo by wowbagger · · Score: 1

    Sorry, the version should have been 2.14, not 2.4.

  21. Why are you only using even-numbered releases? by devphil · · Score: 1


    The even==stable, odd==development pattern is only used by the Linux kernel. (And smaller projects that choose to imitate them.) No other major open source effort does the same thing, because every project manages its time differently.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    1. Re:Why are you only using even-numbered releases? by Anonymous Coward · · Score: 0
      No other major open source effort does the same thing

      Except Perl...

    2. Re:Why are you only using even-numbered releases? by chefren · · Score: 2, Insightful

      Gnome has been doing this as well and as far as I can tell they are fairly major. :)

    3. Re:Why are you only using even-numbered releases? by p3d0 · · Score: 1

      He never said he was only using those releases. Just that those releases broke binary compatibility.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    4. Re:Why are you only using even-numbered releases? by devphil · · Score: 1


      Ah, didn't know that. I'm a KDE guy. :-)

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
    5. Re:Why are you only using even-numbered releases? by devphil · · Score: 1


      But we've broken bincompat more often than that. And he asks about "3.6" when 3.5 hasn't even forked yet.

      --
      You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  22. Fixed C++ ABI ... finally by Dr.Dubious+DDQ · · Score: 0
    I think you're in the same boat I'm in. Care for a bailing bucket?

    Nope, no need it turns out....

    I THINK, like the Linux kernel, the odd-numbered 'minor' releases (e.g. 2.9.x, 3.1.x, 3.3.x, etc.) are the 'development' branches, and the 'even' numbered ones are the 'release' ones...meaning that the binary compatibility changes actually took place in 2.9.x, 3.1.x, and (most importantly for me) 3.3.x.

    In any case, I just dropped out of KDE (QT/KDE are C++...), updated to my newly-compiled 3.4.0 GCC/GCC-G++/GCC-JAVA packages, and restarted. No problems so far running off of the new C++ library it appears. (And I DO remember, I think, having to go through the 'recompile QT/KDE because of binary incompatibility' when I updated to the 3.3.x series...)

    So, it looks like anyone who's been running off of the 3.3 series GCC compilers SHOULD be okay to upgrade.

    1. Re:Fixed C++ ABI ... finally by Dr.Dubious+DDQ · · Score: 1
      I THINK, like the Linux kernel, the odd-numbered 'minor' releases (e.g. 2.9.x, 3.1.x, 3.3.x, etc.) are the 'development' branches, and the 'even' numbered ones are the 'release' ones...meaning that the binary compatibility changes actually took place in 2.9.x, 3.1.x, and (most importantly for me) 3.3.x.

      Yeah, I know, replying to myself...

      A post above contradicts this, so I may be wrong about this...but I DO think I was remembering the binary incompatibility occurring in the 3.3 series correctly in this case. (My impression is that 3.4 doesn't have too many 'new features' beyond 3.3, but had more of a focus on optimizing the compile speed of 3.3.)

    2. Re:Fixed C++ ABI ... finally by cimetmc · · Score: 4, Informative
      A post above contradicts this, so I may be wrong about this...but I DO think I was remembering the binary incompatibility occurring in the 3.3 series correctly in this case. (My impression is that 3.4 doesn't have too many 'new features' beyond 3.3, but had more of a focus on optimizing the compile speed of 3.3.)

      Well, you are wrong in a number of ways:

      1) Like you already noticed yourself, GCC doesn't have the even/odd numbered version logic of Linux. Each version number is a release version. Development versions have the next release version with a date attached to the version. The development process is formalized and is described here

      2) GCC 3.4 is a regular new version with a number of new features. It is certainly not a minor version with just some compile speed tuning. I would consider the changes from 3.3 to 3.4 bigger than the previous changes from 3.2 to 3.3.

      3) The real oddball in the GCC 3.x series is GCC 3.2.x. This is just a bugfix version of GCC 3.1. However as some of the bugs fixed were a major C++ ABI issue and fixing those bugs lead to incompatibility, the GCC developers decicded to exceptionally increment the version number not following the regular release scheme.

      Marcel

  23. New Features by AT · · Score: 4, Informative
    In addition to the usual bug fixes, there are some cool new features in gcc 3.4. Here is the full list; some of the more interesting stuff:
    • unit (file) at a time compilation with -funit-at-a-time; now gcc can finally do some limited global (cross-function) optimization
    • profile feedback (-fprofile-generate -fprofile-use options) that allows gcc to optimize based on feedback from runtime
    • precompiled header files for huge compilation speed gains
    • C++ now much closer to ISO standard
  24. Dr. Dobbs Answers this by Anonymous Coward · · Score: 0

    This issue of Dr. Dobbs gives some answers. Compares a bunch of compiliers.

  25. Thanks for #pragma once by Anonymous Coward · · Score: 2, Informative

    I'm very pleased to see that "#pragma once" has been rewritten and undeprecated in this new release of GCC.

    That makes it easier for me to port Visual C++ code to GCC.

    Thanks a lot.

    Tom.

  26. It should be noted that.. by XaXXon · · Score: 2, Informative

    Precompiled headers were disabled FOR CAUSE in this version.

    There are some known defects in the current precompiled header implementation that will result in compiler crashes in relatively rare situations. Therefore, precompiled headers should be considered a "technology preview" in this release.

  27. gcc -Os (optimize for size) by Per+Abrahamsen · · Score: 1

    The -Os flag has become dramatically better during the 3.x series.