Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Software

GCC 3.4.0 Released 68

Posted by timothy from the deep-infrastructure dept.
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."
This discussion has been archived. No new comments can be posted.

GCC 3.4.0 Released More

GCC 3.4.0 Released

Comments Filter:

  • Not officially released yet (Score:5, Informative)

    by RML ( 135014 ) on Tuesday April 20, 2004 @09:04PM (#8924212)
    This announcement is premature, it's still propagating to mirrors; the "announcment" [gnu.org] is an error. The official release will be tomorrow [gnu.org].

  • pch (Score:3)

    by rmull ( 26174 ) on Tuesday April 20, 2004 @09:07PM (#8924240) Homepage
    Yes! Precompiled headers will be miiiiiiiiine!!!!!

    • Re:pch (Score:4, Informative)

      by 0x0d0a ( 568518 ) on Wednesday April 21, 2004 @12:36AM (#8925634) Journal
      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.
      • There's already ccache [freshmeat.net] 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.
      • 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.

    • PCH and auto* (Score:3, Interesting)

      by greppling ( 601175 )
      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.

  • but who (Score:5, Funny)

    by mithras the prophet ( 579978 ) on Tuesday April 20, 2004 @09:09PM (#8924260) Homepage Journal
    is still using a 386 anymore??? Get with the times, gcc! ;)

    • That's who (Score:3, Insightful)

      by fm6 ( 162816 )
      Well, these guys [orbitmicro.com], these guys [intel.com], and these guys [emjembedded.com] 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.

  • Ideally... (Score:5, Funny)

    by me98411 ( 754004 ) on Tuesday April 20, 2004 @09:10PM (#8924264) Homepage
    Ideally no one would have noticed until tomorrow, when the official announcement will go out..

    They did not think about /., did they?

  • Profiling shared libraries (Score:5, Interesting)

    by wowbagger ( 69688 ) on Tuesday April 20, 2004 @09:57PM (#8924636) Homepage Journal
    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.
    • 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?
    • 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.

  • GCJ (Score:4, Interesting)

    by InsaneCreator ( 209742 ) on Tuesday April 20, 2004 @10:00PM (#8924667)
    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.

    • Re:GCJ (Score:3, Informative)

      by thufir ( 129668 )
      It works nicely with SWT.

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

    • GCJ with Java+QT (Score:3, Informative)

      by bcore ( 705121 )
      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.

    • Re:GCJ (Score:5, Informative)

      by rmathew ( 3745 ) <rmathew @ g m a il.com> on Wednesday April 21, 2004 @05:43AM (#8926820) Homepage
      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 [redhat.com] 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).

    • Re:GCJ (Score:3, Informative)

      by XiC ( 207670 )
      It works like a charm for me using swt on windows.

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

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

  • Thanks (Score:5, Informative)

    by Markus Registrada ( 642224 ) on Tuesday April 20, 2004 @11:16PM (#8925158)
    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.

  • Broken C++ ABI ... again (Score:5, Informative)

    by Lumpish Scholar ( 17107 ) on Tuesday April 20, 2004 @11:26PM (#8925214) Homepage Journal
    They broke binary compatibility in gcc 3.0, and again in 3.2, and now in 3.4 [gnu.org].

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

    • Re:Broken C++ ABI ... again (Score:5, Interesting)

      by Dr.Dubious DDQ ( 11968 ) on Wednesday April 21, 2004 @01:06AM (#8925797) Homepage

      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...

      • 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

        • 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++/GC

          • 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 cas

            • Re:Fixed C++ ABI ... finally (Score:4, Informative)

              by cimetmc ( 602506 ) on Thursday April 22, 2004 @03:25PM (#8942189)
              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 [gnu.org]

              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


    • 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.

  • 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

  • Idle curiosity (Score:3, Interesting)

    by bhima ( 46039 ) <Bhima.Pandava@nOSPaM.gmail.com> on Wednesday April 21, 2004 @04:42AM (#8926638) Journal
    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.

    • Re:Idle curiosity (Score:2, Interesting)

      by CoolGuySteve ( 264277 )
      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
      • 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?

    • Re:Idle curiosity (Score:4, Informative)

      by arkanes ( 521690 ) <arkanes@@@gmail...com> on Wednesday April 21, 2004 @10:01AM (#8928330) Homepage
      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.

  • This may be a stupid question, but... (Score:1, Interesting)

    by Anonymous Coward
    ...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.

  • New Features (Score:5, Informative)

    by AT ( 21754 ) on Wednesday April 21, 2004 @12:18PM (#8929990)
    In addition to the usual bug fixes, there are some cool new features in gcc 3.4. Here [gnu.org] 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

  • Thanks for #pragma once (Score:2, Informative)

    by Anonymous Coward
    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.

Slashdot Top Deals

"Just think, with VLSI we can have 100 ENIACS on a chip!" -- Alan Perlis

Close