Slashdot Mirror


GCC 2.95 Released

sparky writes "The GNU Compiler Collection (GCC) 2.95 is available ."> here [Ed: Please use a mirror]. This is the first release of GCC since the EGCS steering committee took over, and a major step on the way to GCC 3.0. " Interesting to see we have a new ANC (acronym name change).

38 of 206 comments (clear)

  1. Re:pgcc -> gcc? by Jonas+�berg · · Score: 2

    If I understand the situation correctly, pgcc is basically a set of patches against egcs/gcc. A lot of the code from pgcc should make its way into gcc eventually, although I believe that some parts can't be included, such as those written by Intel. That's because the copyright for changes to GCC must be assigned to the FSF, and Intel seems unwilling to do so.

  2. Re:Kernel and GCC 2.95 by Anonymous Coward · · Score: 2

    "Oh, your 2.2 kernel crashed. Did you compile it with egcs?"

    That is a common question on linux-kernel. Yes, the code was cleaned up in this respect. But nevertheless, noone guarantees you that an egcs compiled kernel will work. I still use gcc 2.7.2.3 on production boxes for kernel compiles.

    The difference between egcs and gcc 2.95 is that Mark's aliasing framework is turned on by default. There have been some heavy debates about this on the kernel mailing list and apparently the communication between the egcs team and Linus was not very successful :-/

  3. Re:pgcc -> gcc? by Jonas+�berg · · Score: 2

    I stand corrected then; than you for the information.

  4. Re:Kernel and GCC 2.95 by Anonymous Coward · · Score: 3
    There have been some heavy debates about this on the kernel mailing list and apparently the communication between the egcs team and Linus was not very successful :-/

    Linus is a great guy and all that. But he has some blind spots. Among them are Quality and Engineering issues. He just does not have the background or experience to make good judgements in these areas. He lacks a humility which would tell him that he is not an expert in all areas of computer science. What we are starting to see is that his lack of expertise in some areas has hindered Linux's ability to scale well across architectural and performance bounderies. In other words, the kernel is becoming more and more complex and Linus is unfamiliar with the technologies which could address these issues. And worst of all, he appears to be unwilling to learn.

  5. Re:Sterring. Rhymes with herring. by Jonas+�berg · · Score: 3

    I'd recommend browsing Slashdot with Lynx and using Emacs or some other
    such editor to edit text inputs. It's all very sweet because using an
    external editor makes it so much easier to run ispell.

  6. GCC and Ritchie's compilers by ajs · · Score: 4

    It's great to see the full span of history, here. The previous article was Ritchie releaseing code for the first C compilers and this one is GCC 2.95 which is the culmination of at least 15 years of work on the part of Stallman, FSF, Cygnus and probably tens of thousands of volunteers. For those who are looking to advocate Open Source within their companies, or just see for yourself what this "new" paradigm can produce, please read the GCC source! It's some of the best code I've ever seen (though I admit it has it's... blemishes). The way it achives platform neutrality while producing highly platform-optimizied code is genius, and you can really feel its roots (the intermediate language is a compromise between Stallman's love for LISP and a desire to keep compilation fast and efficient). This is all without going into the fact that there are now front-ends for every major programming language with the exception of the purely interpreted ones (Perl, Python, TCL, etc).

    Currently, as far as I am aware, this is the finest compiler on the face of the Earth, and I dare someone to prove it wrong. There are compilers that produce faster code for a specific platform, and there are compilers for languages that GCC has never heard of, but GCC wins the all-around best technology (IMHO) for producing native instructions from your pet language. It's the one tool which I feel justifies all of Stallman's quirkiness, and gives me faith in the future of Open Source.

    1. Re:GCC and Ritchie's compilers by Trepidity · · Score: 2

      How is pgcc "better" than gcc when it won't even compile PPC code?

    2. Re:GCC and Ritchie's compilers by JoeBuck · · Score: 4

      As a member of the gcc/egcs steering committee, I would be very happy if, in fact, GCC were "the finest compiler on the face of the earth". It isn't. It is the most widely ported compiler, and it's decent enough, but many other compilers beat it for code quality.

      gcc 2.95 still isn't that great on Intel-compatible processors. The good news is that we finally have a new IA32 back end, produced by Cygnus under contract, that has been donated; we'll finally have enough accuracy to do instruction selection and scheduling properly. It will be in gcc 2.96 (or whatever we call it). Until then, pgcc will be better (I believe that the new back end beats pgcc at least most of the time).

  7. Re:Sterring. Rhymes with herring. by ajs · · Score: 2

    Shouldn't it be trivial (with ispell's "-a" mode) to write a web-based interface to integrate with things like Slash?

  8. Re:Ada kernel by Scurrilous+Knave · · Score: 3
    Ada95 supports OO programming, but unlike, say, Smalltalk, it doesn't restrict you to that model. You are correct that an Ada kernel would be easier to maintain, and yes it would be more portable--at least in my experience, Ada is more portable not only between platforms, but between compilers, than C, and even moreso than C++. The "not as efficient" is a myth. One can write inefficient code in any language. Real efficiency comes from choosing your algorithms wisely--a warrior thinks of tactics, a good warrior of strategy, but a great warrior thinks of logistics. And besides all that, since an Ada compiler has more information than, say, a C compiler, about what the programmer actually wants, it can make better decisions and actually generate more efficient code, especially for today's pipelined multiple-functional-unit CPUs. Not that GNU Ada necessarily does better than GNU C, but in practice the efficiency question is a red herring.

    I applaud the fact that you didn't just blindly flame what you do not know. I would suggest that you learn a bit about it--who knows, you might like it!

  9. Re:Kernel and GCC 2.95 by Trepidity · · Score: 2

    Is there any indication from any Important People(tm) when this bug in the kernel will be patched?

  10. Re:Kernel and GCC 2.95 by devphil · · Score: 2

    Hit the egcs mailing list archives off of the
    egcs homepage. There is a long, long collection
    of threads about this problem, dealing especially
    with the Linux kernel. Linus Himself[tm] gets
    heavily involved.

    Parts of it turn into a flamefest, but there
    /is/ a good deal of information down in there as
    well.

    In any case, it's not a showstopping bug; you
    just have to use a flag.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  11. C++ is not OO, it's multi-paradigm by Anonymous Coward · · Score: 2

    C++ is not OO, it's multi-paradigm.
    It means that it supports the combined use of classic low-level structured programming (C), object-oriented programming (Simula), and template programming / stronger typing (Ada).

    SmallTalk is 100% pure Object. Java is around 75%.

    Now, my opinion: C++ is overcomplicated, mostly because it is too low level and high level at the same time.

  12. Re:Upgrade consequences? by Cadaver · · Score: 2

    Compile kernel 2.0 only with gcc 2.7.2; compile kernel 2.2 with -fno-strict-aliasing enabled as a CFLAG in arch/i386/Makefile, and you'll need to edit the configure script for glibc2.1.1 to get that working (and, of course, you need to set CFLAGS=-fno-strict-aliasing with this as well)

    --
    I ate something that disagreed with me. Maybe I should have cooked him first.
  13. Re:Java != OO? by bt · · Score: 2

    I think it depends on the project. In some places Java speeds up the process of coding because so much is abstracted. And smalltalk can speed it up even more (although I'd use Java or C++ before Smalltalk), but don't waste your time with "Hello world!" and trivial stuff like that in Smalltalk...

  14. Re:RH6 RPM's? by Archangel_ · · Score: 2
    Best place to try is ftp.redhat.com/rawhide, or ftp.redhat.com/contrib, and if cant find it there try www.freshmeat.net. If don't know how to make rpm spec files, there are tools available that could help you to make rpms:

    installwatch

    gnome rpm work station

    I could list more....just go to www.freshmeat.net and search for rpm.

    --
    "Gravity must be scholastic occult quality or the effect of a miracle."
  15. Re:RH6 RPM's? by Gleef · · Score: 2

    You can't get RPM's for this yet, it's just been released! You'll be able to get them when someone makes them, and you'll surely be able to get them at the Rufus RPM Repository. In the mean time, you can try compiling it yourself from the released source. Even better, you can make your own RPM of it, go to RPM.org to learn how (Maximum RPM is a great book).

    ----

    --

    ----
    Open mind, insert foot.
  16. Performance of g++ vs. competition under Linux by jaffray · · Score: 2
    Anyone want to comment on the speed of g++ compiled code compared to other C++ compilers? I'm writing a performance-critical C++ application and wouldn't mind getting 10-20% speedup for free. But if g++ is within 1-2% of the fastest out there, it's not worth messing with for now.

    KAI C++ makes grand performance claims, and Comeau is another compiler built on the same ECG backend (but much cheaper). I'm mainly interested in the Linux platform for now.

    Notes:
    1. Language trolls can buzz off, I'm aware of the performance issues of using C++ vs. C.
    2. I know KCC has a time-limited demo, and I've downloaded it, but it looks like it's much stricter about the C++ it accepts; it might take a while to get my code to compile with it, which is why I'd like to get some feedback before deciding whether or not to mess with it.
  17. Re:Huray! Now, more people use C++!! by sjames · · Score: 2

    C++ has it's pros and cons like every other language. Likewise, it is better suited to some applications than others. C++ code can be syntactically cleaner, and more maintainable, or it can be MFC.

    It's biggest drawback is that it can obfuscate inefficiencies in code. What looks like a simple assign (or memcpy) can end up serializing and parsing at a high cost.

    It may not even be bad coding when the objects are implemented that way (perhaps the 'assigns' are never done in performance critical areas and the marshalling is needed for interoperability.) The problem starts when sombody else has to maintain the code. They end up loosing the advantages of OO code because they either have inefficient code, or have to study the objects and their relationships just as deeply as they would in C.

    Personally, I find that by the time I dig through C++ code (for the fabled ease of code reuse) to check for those problems, it would have been just as easy to cut/paste C code. If the objects are available in library form only, it just means that you either end up with wrappers looking like chinese boxes (so that doing anything involves too many pointer dereferences internally), or you end up with a dozen similar objects that all inherit from the same base and do the same thing in slightly different ways.

    C++ does have a few nice features. Most of those seem to be in the process of back-porting into the C standard.

    Some things call for C++, others call for C, Perl, or Lisp. Some few things even call for assembly.

    While it is true you can write OO-like code in C, why would you want to?

    In cases where OO is the right approach, but I want to make the cost of various operations quite explicit. The Linux kernal is written that way.

  18. Re:Kernel and GCC 2.95 by Anonymous Coward · · Score: 2

    > There have been some heavy debates about this on the kernel mailing list and apparently the
    > communication between the egcs team and Linus was not very successful :-/

    I don't understand that...

    What do you expect?
    Should the egcs team hack the compiler to work around "missbehaviours" in the linux sources?!?

    Linux that has the problem, *not* egcs. Nearly all other pieces of software (incl. other kernels) compile and work just fine with egcs.

  19. Link by Axe · · Score: 2

    Here

    Citation..
    (1) Code Fusion produces code that is 85 percent faster than the current Net GNU release, 20 percent faster than the Microsoft Visual C++ 6.0, and equivalent to Intel's Proton compiler. These results are based on the Integer Index performance in the byte benchmark.

    --
    <^>_<(ô ô)>_<^>
  20. Re:Huray! Now, more people use C++!! by Jordy · · Score: 2

    Oh lord, another language war.

    C++ and other OO languages have been proven to be more efficient for programmers on projects larger than 100k lines.

    It takes less time for a programmer to start working with a large codebase written in C++ than in C plain and simple.

    For example, I was able to make modifications to a bug in Mozilla roughly 20 minutes after I first took a look at the source. When you break your namespace for functions and variables down into peices the way C++ does, it is easier to digest.

    While it is true you can write OO-like code in C, why would you want to? C++ is just an extension of C; all the functionality of C is included in C++ at a minimal cost.

    --

    --
    The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
  21. More backward compatability by tardis · · Score: 2

    So, has anyone had anyone had any luck getting this to compile with
    last1120c or prestruct-c?

  22. Performance of compiled binaries compared to pgcc by ghazban · · Score: 2

    What is the performance of binaries compiled with gcc 2.95 compared to that of binaries compiled by pgcc and will the source changes that pgcc has made to egcs be envtually returned to the main source tree?

    Cheers
    Lucas

  23. Re:GNU IA32? by zudark · · Score: 2

    Nope, the new_ia32_branch is not folded into
    2.95. If you cvs co it its version number is
    2.96 right now, but I don't know when the merge
    will occur.

  24. Re:Kernel and GCC 2.95 by dvdeug · · Score: 2

    When the alias issue came up, Linus told the compiler people to use a set of rules to turn aliasing off, instead of immediately correcting the bug in Linux (it is a bug, because it violates ANSI C aliasing rules, and he was shown at least two ways to fix it.)

    That's not good engineering, to write buggy code and expect other people to fix the tools to work around your buggy code.

  25. Re:Kernel and GCC 2.95 by JoeBuck · · Score: 2

    To compile Linux 2.2x with gcc 2.95, you need to include the flag -fno-strict-aliasing

    This flag is needed if you have code that does things like try to read an array of longs as an array of shorts, without using unions.

  26. Thanks by Anonymous Coward · · Score: 3

    Since nobody here have really said it I want
    to say thank you to all developers that spend
    their time making gcc better.

    I use gcc/g++ almost every day and I am very pleased with it.

  27. Web pages by Jonas+�berg · · Score: 3
    Now then, before anyone comes bursting in saying that we havn't updated the web pages: look again. I just updated the web pages on www.gnu.org and I hope that the steering committee will update their web pages on gcc.gnu.org soon too. It's the idea that eventually the web pages from gcc.gnu.org will magically appear att www.gnu.org, possibly with some small stylistic changes, but we havn't gotten around to this yet.

    As a blatant plug I'd also like to say that the GNU Webmasters need more help. Do write me if you want to help out.

  28. pgcc -> gcc? by pli · · Score: 2

    Will pgcc be merged with gcc, or what is that status of that?

    1. Re:pgcc -> gcc? by JoeBuck · · Score: 2

      The need for pgcc should be eliminated by the new IA32 back end (which isn't in 2.95, but will be in the next major release).

      I don't believe that there is any copyright assignment issue for the pgcc patches. The real issue was that Intel didn't do things "right". Their way of modifying the compiler was to ignore the distinction between the front end (portable) and the back end (processor specific), so pgcc is an Intel-only compiler as a result. This means that the Intel patches would need to be redesigned. Some of them already have been and are already in.

  29. Kernel and GCC 2.95 by Kento · · Score: 5

    I was just reading the linux kernel mailing list (which i *just* resubscribed to) and apparently, the kernel won't compile correctly with gcc 2.95. Here's an excerpt:

    The linux kernel violates certain aliasing
    rules specified in the ANSI/ISO
    standard. Starting with GCC 2.95, the gcc
    optimizer by default relies on these
    rules to produce more efficient code and thus
    will produce malfunctioning
    kernels. To work around this
    problem, the flag -fno-strict-aliasing must be
    added to the CFLAGS variable in
    the main kernel Makefile.

    Disclaimer: I haven't downloaded the new compiler and so I haven't tried it yet, but keep this in mind when you upgrade gcc.

    1. Re:Kernel and GCC 2.95 by sterwill · · Score: 3

      I understand how easy it is to criticize Linus from behind the security blanket you call anonymitiy, and I can't disagree with all your points, but I'm not sure you understand Linus's position (perhaps you understand it better than I). The kernel tree is very large, and I wouldn't want the job of coordinating all the development that goes on within. Just reading the linux-kernel mailing list is a job in itself.

      I admire the job Linus is doing but I can't imagine a single person doing it any better. I've always found Linus a humble guy in the end. Show him something's really better your way, and in a way he can understand (considering the other work he does), and often he'll adopt it. He's made an occasional policy or kernel decision that might have upset me, but coordinating public devlopment can be acurately described as herding cats. It's an endless series of tradeoffs because everyone wants to go his own way; sometimes patches are rejected, sometimes the ideas they implement become the center of rabid e-mail debate, and sometimes they're quietly applied.

      The sheer numbers of developers and different directions and goals of each pulls on Linus in a different direction. I've used Linux on a variety of architectures, and I wish Linus would focus more on keeping 'stable' release of the kernel clean across all architectures--these are the quality issues of which you speak. 2.2.10, for example, won't compile on an Alpha.

      I can't say I see Linus holding back the performance of the kernel for reasons of stubbornness. Most of the performance improvement suggestions he receives present a risk in other areas (stability, security, portability). He's making trade-offs, and I personally admire most of the decisions he's making.

      Scalability and performance issues are most often encountered when trying to make the Intel architecture do something it was never intended to do: be scalable. I think it's unfortunate that so many people continue to squeeze this twenty-year-old idol of cruft into such places when cleaner and better engineered alternatives exist.

      I think he's doing a very good job.

    2. Re:Kernel and GCC 2.95 by Anonymous Coward · · Score: 2

      That's nothing new. The same statement was also true for egcs 1.1.x. Compiling the Linux kernel using egcs was always dangerous since it relies on some non-standard aspects (bugs) of gcc 2.7.2.

    3. Re:Kernel and GCC 2.95 by Kento · · Score: 3

      The 2.0 kernels used illegal inline assembly constructs which just happened to work with GCC 2.7.2 . You could always compile the 2.2 kernels with whatever compiler you wanted. From what I can tell, this is different, and it affects all kernels, including the 2.2 ones.

  30. Upgrade consequences? by Rob+Kaper · · Score: 2
    This is all great of course (new releases always are), but would it have been too hard to post a little note with upgrade consequences with this announcement?

    Will it break my system? What are the requirements? Will the kernels compile with it? how about other large projects such as X, Apache, Gnome, KDE.

    The compiler is one of the core programs if you don't use binaries so the over-all stability of your Linux box greatly depends on a good combination of compiler, libraries, includes etc etc.

    Is there a HOW-TO available on this? (not just saying: "old goes with old and new with new" or providing upgrade instructions for a specific compiler but more a general document describing how some parts of the system work together and how to make optimal use of that)

  31. Re:egcs replaces gcc and egcs renamed to GCC by JoeBuck · · Score: 2

    We tried to ask you, but since you posted as Anonymous Coward we couldn't find you. Since we lacked your enormous wisdom, we, in our lesser wisdom, called it GCC.

    We considered the name "gcs". We decided to keep "gcc" because that's the name most people know; had we chosen any name but "gcc" some clueless folks would have kept running gcc-2.8.1 forever. Besides, we'd break every makefile in the world if we changed the name users type.

    Don't get hung up on capitals versus lower case. Remember, when you invoke the command "gcc", it will happily build C, C++, Objective-C, Fortran, Java, or Chill for you. So gcc is the GNU Compiler Collection.

  32. Sterring. Rhymes with herring. by Russ+Nelson · · Score: 2

    Hmmm.... You'd think slash would be integrated with a spel checker by now.
    -russ

    --
    Don't piss off The Angry Economist