Slashdot Mirror


GCC 4.0.0 Released

busfahrer writes "Version 4.0.0 of the GNU Compiler Collection has been released. You can read the changelog or you can download the source tarball. The new version finally features SSA for trees, allowing for a completely new optimization framework." The changelog is pretty lengthy, and there's updates for every language supported from Ada to Java in addition to the usual flavors of C.

158 of 680 comments (clear)

  1. Moving fast by slapout · · Score: 4, Interesting

    Is it just me or did the jump from version 3 to 4 happen a lot faster than the one from 2 to 3?

    --
    Coder's Stone: The programming language quick ref for iPad
    1. Re:Moving fast by ari_j · · Score: 4, Funny

      There was a version 3?

    2. Re:Moving fast by JohnsonWax · · Score: 5, Interesting

      Apple wasn't working on GCC until version 3. I suspect a lot of other companies weren't either.

    3. Re:Moving fast by burns210 · · Score: 4, Interesting

      Apple is using it in their Tiger (OS X 10.4) release come the 29th of this month. So there is a few millions new GCC 4.0 users right there.

    4. Re:Moving fast by Anonymous Coward · · Score: 5, Funny

      Yes, it came with Slackware 5 and 6.

    5. Re:Moving fast by Anonymous Coward · · Score: 3, Insightful

      There are a hell of a lot more users that depend on GCC then the paltry Apple userbase.

      GCC is pretty much the standard for the industry.. there are faster, and more specialized, but GCC is the standard.

      Linux/Unix/BSD/etc, IBM, servers, clients, embedded platforms, all hosts of different computers.

      Hell if you just look at the embedded computers there are more of those then all the different desktop computers (Windows + *nix + Apple) put together.

    6. Re:Moving fast by Dink+Paisy · · Score: 2, Informative

      Well, there was the whole stagnation on 2, leading to the egcs fork and eventual reconciliation with the FSF branch. So it's not really surprising that development is happening a whole lot faster now.

      --

      Whoever corrects a mocker invites insult;
      whoever rebukes a wicked man incurs abuse.
      --Proverbs 9:7
    7. Re:Moving fast by adamjaskie · · Score: 2, Informative

      It was a joke. There WAS no Slackware 5. Or 6.

      --
      /usr/games/fortune
    8. Re:Moving fast by paulymer5 · · Score: 2, Interesting

      No, most Mac applications will soon be using the new version.

      Users, when discussing a compiler, is a nebulous term. Does one mean programmers developing for the compiler, or does one mean any person using the compiler directly through source or indirectly through binaries?

      I consider the latter more significant; autovectorization will be extremely important on G4 and G5 hardware, and Mac OS X binaries (by far the most popular distribution method for the platform) will soon reflect this.

    9. Re:Moving fast by ConceptJunkie · · Score: 2, Funny

      According to Slashdot users, I'm funny, insightful and interesting! So why aren't girls all over me?

      'Cause we (the people who find you funny, insightful and interesting) are pasty couch potatoes just like you. ;-)

      --
      You are in a maze of twisty little passages, all alike.
    10. Re:Moving fast by smokeslikeapoet · · Score: 3, Funny

      Mine was Gentoo 1.4, by the time I had it compiled it was 2004.3. Talk about a time warp.

    11. Re:Moving fast by bani · · Score: 2, Informative

      autovectorization is nice, but its like a peephole optimizer. it optimizes small bits of code.

      in terms of technology, SSA is far more important as it optimizes "the big picture".

    12. Re:Moving fast by Bradee-oh! · · Score: 3, Funny

      >Consider me slow.

      Done.

      --
      "This is Zombo Com, and welcome to you who have come to Zombo Com" - www.zombo.com
    13. Re:Moving fast by InvalidError · · Score: 2, Funny

      Or...

      "And next time I get mod points, you will also be overrated, redundant, flamebait and a troll."

    14. Re:Moving fast by paulymer5 · · Score: 4, Insightful

      Absolutely.

      However, I was referring to the underutilization of Altivec in G4/G5 environments. Whereas SSA will be excellent across platforms, autovectorization will be especially significant on chipsets with powerful vector processors.

      Being able to optimize for this hardware, which is not as common or powerful in the x86 world, without much effort is indeed significant.

      I do not disagree with your assessment in the relative worth of SSA and vectorization, but I would simply like to clarify my post.

    15. Re:Moving fast by Billly+Gates · · Score: 2, Funny

      Debian user?

    16. Re:Moving fast by garbletext · · Score: 2, Insightful
      I do not disagree with your assessment in the relative worth of SSA and vectorization, but I would simply like to clarify my post.
      If more people took the time to do things like this, slashdot would be a happier place. I commend you.
    17. Re:Moving fast by Capt+James+McCarthy · · Score: 3, Funny

      Dude, this is the PC days, as we prefer the term "physically uninterested" as opposed to "couch potato."

      --
      There are no loopholes. It's either legal or it's not.
    18. Re:Moving fast by stitch · · Score: 2, Funny

      According to Slashdot users, I'm funny, insightful and interesting! So why aren't girls all over me?
      Ah, sorry about that. I'll lend you one when I'm finished.

    19. Re:Moving fast by Kazymyr · · Score: 2, Informative

      Yeah I know most people will chime in to say there never was a Slackware 5, but I happen to have a burned copy of it. :)

      [Slack 5 was the name it held in the beta or "current", which was later released as 7.0]

      --
      I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
    20. Re:Moving fast by malxau · · Score: 2, Informative

      I have a prerelease build of OS X built with gcc 2.7. I remember the Apple engineers wanted to ship the original OS X with gcc 3.x, but 'it just wouldn't make it' and they used 2.96 instead. OS X 10.0 and 10.1 were built on that compiler.

  2. Lisp? by ari_j · · Score: 4, Funny

    Yeah, but does it have a Common Lisp compiler yet?

    1. Re:Lisp? by sketerpot · · Score: 4, Informative

      Try SBCL, CMUCL, GCL, or CLISP. They're all good Lisp implementations. SBCL and CMUCL compile to native code directly and are probably the fastest free CL implemetations, GCL compiles via C (and therefore GCC), and CLISP has a bytecode interpreter.

    2. Re:Lisp? by jm92956n · · Score: 5, Funny
      every language supported from Ada to Java

      From A to J. Lisp starts with an L.

      Therefore, according to the summary... no.

      --
      An effective signature identifies a particular user amongst a base of thousands.
    3. Re:Lisp? by Theatetus · · Score: 4, Informative

      Yes, gcl (formerly known as kyoto common lisp). But it doesn't need the assembler/linker part of the toolchain so it's packaged separately. But I think it is "Part of the GNU Compiler Collection", for what that's worth, and it does depend on GCC.

      --
      All's true that is mistrusted
    4. Re:Lisp? by tchernobog · · Score: 2, Funny

      Oh, no!
      Still no support for LOGO, then!
      I've been waiting it for *years*!

      --
      42.
  3. i'm having horrible flashbacks... by ribo-bailey · · Score: 4, Interesting

    of the 2.95 -> 3.0 transition.

    1. Re:i'm having horrible flashbacks... by whovian · · Score: 2, Funny

      Keep your hands inside the moving vehicle.

      Just over a week ago Fedora Core 3 got its gcc4 package. Not that there's anything wrong with that, as long as it's a supported gcc version *cough*2.96*cough*

      --
      To-do List: Receive telemarketing call during a tornado warning. Check.
    2. Re:i'm having horrible flashbacks... by den_erpel · · Score: 2, Interesting

      Ah things no longer compiling :) True, it was very annoying and made you go through an extra code review while porting your code forward.

      In the long term, I think it was a very good thing: coding C (and C++, but didn't have that much experience on that) got much more stickt and in my experience, removes a lot of possible problems later on.

      If someone had a lot of problems porting 2.95 to 3.2, his code needed to be reveiwed anyway. It kind of removes the "boy" from "cowboys" in coders (experience is drawn from not-so-embedded systems).

      Based on the remarks obtained from the compiler for embedded code (they made a lot of sense) during the switch and gcc becoming more strict, we now even compile everything with -Werror.

      In our deeply embedded networking code, we got a speed improvement of 20% just switching to 3.4 (from 3.3) :) I am going to try to compile a new PowerPC toolchain one of these...

      Go GCC!

      --
      Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
    3. Re:i'm having horrible flashbacks... by __aahlyu4518 · · Score: 3, Funny

      ... kind of removes the "boy" from "cowboys" ...

      Which results in..... cows :-)

    4. Re:i'm having horrible flashbacks... by den_erpel · · Score: 2, Funny

      Which results in..... cows :-)

      I'm hoping for a mutation into GNUs :-P

      --
      Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
  4. Is anyone else curious what SSA trees are? by Da+w00t · · Score: 4, Interesting

    Not a C coder myself, (sticking mainly to perl).. I've just got to ask, what are SSA trees, and what benefit do they serve?

    --

    da w00t. mtfnpy?
    1. Re:Is anyone else curious what SSA trees are? by rbarreira · · Score: 3, Interesting

      An educated guess - are they a move in the direction of making code optimizations in gcc easier to code? I heard that a lot of optimization experts (you need to know a lot of graph theory for example) wouldn't work on gcc because of the difficulty of working with it for optimizations, so they would do their experiments in other compilers...

      --

      The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
    2. Re:Is anyone else curious what SSA trees are? by Entrope · · Score: 5, Informative

      Single static assignment is a way the compiler can rewrite the code (usually for optimization purposes) so each "variable" being analyzed is only written once. This makes a lot of optimizations easier to do, since it eliminates aliasing due to the programmer assigning different values to the same variable. You'd probably learn these things if you would RTFA.

    3. Re:Is anyone else curious what SSA trees are? by hey+hey+hey · · Score: 4, Informative

      Static Single Assignment, optimization techniques. Try here for more details.

    4. Re:Is anyone else curious what SSA trees are? by GillBates0 · · Score: 5, Informative
      Wikipedia (as usual) has a nice article about the Static Single Assignment (SSA) form.

      To put it simply, SSA is an intermediate representation where each variable in a block is defined only *once*. If a variable is defined multiple times, the target of any subsequent definitions of the same variable is replaced by a new variable name.

      SSA helps to simplify later optimizations passes of a compiler (for example: eliminating unused definitions, etc) as described in greater detail (with examples and flowcharts) in the article linked to.

      That's the SSA form in short. Now I need to ask somebody the difference between the standard SSA form and "SSA for trees".

      --
      An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
    5. Re:Is anyone else curious what SSA trees are? by tepples · · Score: 2, Informative

      does this mean executables compiled with GCC 4 and optimized properly will run faster?

      In the long run, yes. But for now, I'd imagine that because the SSA form is so new to the GCC codebase, the GCC maintainers are waiting for latent bugs to surface and be fixed before squeezing the most wizardly optimizations out of the SSA tree.

    6. Re:Is anyone else curious what SSA trees are? by Dink+Paisy · · Score: 4, Informative
      As other people have said, SSA is static single assignment. It means that each variable in the program is assigned in only one place. SSA is for optimization, and is usually done in intermediate forms generated by the compiler, rather than in programs written by a human in common computer languages such as C, C++, Perl or assembly languages.

      Trying to recall my knowledge of optimizing compilers:

      SSA makes optimization easier, since it is obvious where a variable was assigned (since it was assigned in only one location) and what value it contains (since there is only one value being assigned to it). The complexity moves to register allocation, where there can be many more variables to allocate because of SSA. Register allocation is Hard, but doing an ok job is quite possible. Most optimizations are impossible unless you can prove various properties about the variables involved, which is often much easier with variables in SSA form.

      --

      Whoever corrects a mocker invites insult;
      whoever rebukes a wicked man incurs abuse.
      --Proverbs 9:7
    7. Re:Is anyone else curious what SSA trees are? by ScytheBlade1 · · Score: 2, Informative

      Not that pertains to SSA trees, but...

      I wanted to know the differences in the optimization levels, so I made up a script[1] that compiled zlib and libpng with various optimizations on various archs and timed how long it took to run the test suite with 4 various images[2][3][4][5].

      I ran this test on a 2.8GHz Intel P4 HT proc, with 512MB Kingston HyperX DDR-400. Results are here.

      The X axis, is in the format "L-Z", where "L" is the libpng optimization level (3, 2, 1, 0, or s (size)), and "Z" is the zlib optimization level (3, 2, 1, 0, or s (size)). The Y axis is in seconds, and for precise values, look at the graph data vs the visual graph.

      The google logo[3] was useless, it's far too small to give me accurate results. However, if you compare the comic[5], the difference is 0.665 seconds... while this may not seem *huge*, in the case of a server where every tenth of a second counts, multiply the time by requests and compare the two. In the simple case of a libpng test case (opens a PNG image, re-writes it, compares the old to the new), optimizations matter, and a lot.

      Of course, some code can be optimized more than others, and there is a large number of variables to take into account, but I'd hope that booting into single user mode and running this in a terminal should remove as much of that as possible.

      The thing is, very few people are going to notice the 2/3rds of a second optimizations give you, vs the hours spent compiling OpenOffice.


      Not linked due to bandwidth reasons (384kbps upstream = teh suck)
      [1]http://www.brantleyonline.com/sf.sh
      [2] Tranqulity - @ gallery.artofgregmartin.com - down due to bandwidth, but it's a 1.4MB file (PNG format), 1600x1200, using a large variety of blues and blacks.
      [3]http://www.google.com/intl/en/images/logo.gif
      [4]Screenshot of OSX on dual monitors, large amount of windows, varied transparancies, 1440x576, 570.2kb. (not linked due to bandwidth)
      [5]http://www.applegeeks.com/comic_archive/viewcom ic.php?issue=134
      Note: if you use the script, please, PLEASE, mirror the images LOCALLY and use that instead...

    8. Re:Is anyone else curious what SSA trees are? by mindriot · · Score: 4, Informative

      Hmm. Funny. Seems like perfect timing, in retrospect. I just held a presentation on SSA (and efficiently transforming code into SSA) today.

      Get the slides here.

      HTH

    9. Re:Is anyone else curious what SSA trees are? by IvyMike · · Score: 5, Informative

      There have been several good answers to your question, but if you're really new to compilers, you might want a little more context. Want a quick lesson in how compilers work? If you're willing to accept some gross oversimplifications, here's how most modern compilers work:

      1) Tokenize the input. For example, if you were compiling perl, you might choose to turn "print $foo" into three tokens; KEYWORD_PRINT, TYPE_SCALAR, and IDENTIFIER('foo'). The output is typically a stream of tokens. This step might be done by lex or flex.

      2) Parse the sequence of tokens using a set of rules called a grammar. For example, "TYPE_SCALAR" followed by "IDENTIFIER()" is might match a rule to generate a variable called "$foo", and "KEYWORD_PRINT" followed by a variable means call the function print on the contents of the variable. The output is typically an abstract syntax tree (AST); a high-level data structure representing the program. This step might be done by yacc or bison.

      3) Match the AST against a series of rules to output the final code. This might actually be two steps; you might generate something into a low-level register transfer language (RTL) that looks very much like assembly, and then turn THAT into actual machine instructions.

      At each stage, you might choose to optimize the output. You might also insert optimizations passes between steps. (For example, you might insert a pass between 2 and 3 to optimize the AST into a simpler AST.)

      Before SSA, GCC sort of skipped making any high-level AST; it used to go from parsing almost immediately into a RTL. You can still optimize RTL, but since it's pretty low-level, it misses out on higher-level context and made some optimizations really difficult.

      SSA is simply a form used for the high-level AST. Why SSA? It is a very nice form to optimize. Read the wikipedia article for more details on why SSA is particularly useful for some optimizations.

      Page 181 of this PDF file from the 2003 GCC Summit explains the flow of the GCC compiler.

    10. Re:Is anyone else curious what SSA trees are? by ZephyrXero · · Score: 2, Funny

      Great...now I have to wait for GCC 4.2 :P

      --
      "A truly wise man realizes he knows nothing."
  5. Sweetness by kronak · · Score: 5, Informative

    Glad to see they are targeting the AMD64 architecture for improvements.

  6. debian by Anonymous Coward · · Score: 5, Funny

    i wonder when debian sid will integrate GCC 4.0...

    1. Re:debian by dhakbar · · Score: 5, Insightful

      I am curious why this AC's comment was modded troll. Is Debian's release cycle truly so slow that what appears to be an honest curiosity is modded as a troll?

    2. Re:debian by alehmann · · Score: 5, Funny

      Pretty much, yeah.

    3. Re:debian by Mongoose · · Score: 4, Informative

      Debian has had pre-releases for 4.0 for a while now. I guess you'd know that if you were a developer and actually used Debian. Hell I have mono 1.1.6 on Debian -- not many distros even have that yet. =)

    4. Re:debian by Anonymous Coward · · Score: 3, Interesting

      Is Debian's release cycle truly so slow that what appears to be an honest curiosity is modded as a troll?

      Kidding aside, no. Debian is legendary for being, ahem, slow about releases; they release when it's done, not on some date. Thus /. gets lots of jokes about Debian being slow. "I heard that Duke Nukem Forever will be open source and part of Debian's next release!!!11!" etc.

      If GCC 4.0 made changes that would affect the ability of the linker to link things, then GCC 4.0 would actually be slow to go into Debian. Packages would probably show up right away in Debian Experimental but otherwise would stay out for a long time.

      Debian Unstable ("sid") is where the new, potentially unstable, stuff goes once it is out of Experimental. Things in Unstable are automatically promoted into Testing if they look stable, which means the Debian guys can't put anything half-baked into Unstable. They would have to wait until the current Testing is released as Stable, and then they could do a big change like that. The current Testing ("sarge") is getting closer to actually shipping but I don't know when exactly.

      As long as GCC 4.0 simply produces better code, and doesn't break anything, it will show up in Unstable within a very short amount of time. I don't know enough about it to tell you whether this will happen or not, but I did read the release notes and I don't see anything in there that looks like linker breakage.

    5. Re:debian by thomasweber · · Score: 3, Informative

      > Is Debian's release cycle truly so slow that what appears to be an honest curiosity is modded as a troll?
      As Debian sid is the unstable branch of Debian, the release cycle is pretty unimportant for gcc's inclusion. Looking at the experimental branch, you'll find gcc 4.0 already included: http://packages.debian.org/experimental/devel/
      (w hich is probably an earlier release candidate).

      In sid itself exists a snapshot of gcc as of 20050319.

    6. Re:debian by mrtom852 · · Score: 2, Informative

      For the impatient...

      deb http://ftp.us.debian.org/debian/ ../project/experimental main contrib non-free

      apt-get -t experimental update
      apt-get -t experimental install g++-4.0 gcc-4.0
  7. whoa by william_w_bush · · Score: 4, Interesting

    reading tfa and changelog intrigued me. optimisations aside im curious if this will be better able to thread on the new multi-core systems coming out, as tls has been spotty till 3.3 and glibc 2. maybe native xd support coming soon too?

    also, the c++ side makes me feel optimistic about ongoing support, which had been a big problem till 3.4.

    yes im x86/64 centric.

    --
    The first rule of USENET is you do not talk about USENET.
    1. Re:whoa by AHumbleOpinion · · Score: 3, Interesting

      ... I assume these extensions you speak of don't involve automatically adding threads to a program ...

      Actually they do just that. You put a #pragma omp before a for loop to have it implemented using threads. You put another #pragma omp before access to a shared variable to have access serialized. You never code to a specific API. The compiler automatically generates pthread calls, Win32 calls, etc as appropriate. Your code is portable. Lawrence Livermore has some nice examples but the seem to be down right now, www.llnl.gov.

  8. works great! by k4_pacific · · Score: 3, Funny

    I've already downloaded it and used it to recompile Firefox and I must say that gf@fd@k3nl&
    NO CARRIER

    --
    Unknown host pong.
    1. Re:works great! by NanoGator · · Score: 2, Funny

      "I've already downloaded it and used it to recompile Firefox and I must say that gf@fd@k3nl&
      NO CARRIER"


      So... what.. did you have FireFox open while trying to compile it?

      --
      "Derp de derp."
    2. Re:works great! by Foxxz · · Score: 4, Funny

      It looks like you used it to recompile your kernel or pppd program too!

      -foxxz

    3. Re:works great! by Anonymous Coward · · Score: 2, Informative

      I'm posting right now with Firefox CVS code compiled tonight with GCC 4.0.0 20050418 (prerelease). I just finished building GCC 4.0 a bit ago and Firefox is now compiling. I've seen no problems with the GCC prerelease builds from the last few weeks. Firefox seems a little more responsive than with builds using GCC 3.4.3.

    4. Re:works great! by Anonymous Coward · · Score: 5, Funny

      > I'm amazed that the NO CARRIER joke can be mode so often, and always get modded funny.

      It doesn't always get modded fun&@^4-- NO CARRIER

  9. Re:Great Timing by Rubel · · Score: 4, Informative
    Although the version of GCC 4 that Apple ships is from last October:
    gcc version 4.0.0 20041026
  10. Trees by goodbadorugly · · Score: 4, Funny
    The new version finally features SSA for trees,

    So I guess its pretty safe to say that this release is for the birds

    *ducks*

  11. Why? by Mr.+Underbridge · · Score: 4, Funny
    of the 2.95 -> 3.0 transition.

    Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?

    I'm sure all the contractors loved it! ;)

    GCC motto: "What code can we break today?

    1. Re:Why? by Sivar · · Score: 5, Insightful

      I know you were just poking fun but--

      Standards are the reason that computers are tolerable to use for any purpose.
      If a programmer can't be bothered to follow an international standard of his own language, there is no guarantee that the code is future-proof. One can hardly blame the compiler vendor, as we can't expect a compiler to mindlessly maintain backwards compatibility with every weird use of a bug and every bizarre code construct that has ever been supported in the past.

      The ability to compile code written for GCC in another compiler is a *good* thing. If it requires informing the programmer that their code has always been broken, then so be it. A little inconvenience is a small price to pay for standards compliance, or should we expect that the GCC authors "embrace and extend" C and other languages until so much code relies on weird GCC nuggets that programmers (and users) are "locked in" to using just that compiler? (But Douglas Adams forbid if Microsoft does the same thing!)

      Maybe I am missing something. If so, please enlighten me (This is not a sarcastic remark--I haven't done much research on what 4.0 has broken so I may be way out of line).

      Sheesh, for as hard as the GCC authors work, and for as much GCC has improved in the last 10 years, the contributers sure get a lot of flak. Anyone who doesn't contribute code themselves should be greatful (or at least appreciative) of their efforts, even when they do make mistakes.

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    2. Re:Why? by Theatetus · · Score: 2, Informative

      Man... I'd almost forgotten. the 5/6 libc switch was horrendous, much worse than the 2/3 gcc switch.

      Another big problem was that a lot of the early proprietary Linux software vendors hopped on board right before both of those switches, so there were a boatload of closed-source apps requiring ecgs and a patched libc5 or some other bizarre combination.

      --
      All's true that is mistrusted
    3. Re:Why? by Anonymous Coward · · Score: 3, Informative

      Maybe I am missing something. If so, please enlighten me

      It frustrates me because I don't think older open source projects should just mysteriously break. For example, I have an older sublaptop which I got pretty cheaply on Ebay. There is some someware I would like to try on this machine, such as the last pre-Gecko version of Mozilla (which had a not of Netscape 4 code in it), that I can't get to compile in Gcc 3.4 because too much has changed since then.

      I don't like the fact the gcc breaks code the used to compile fine just two years ago. Another example: Abiword 1.x. Compiled just fine in 2002. Won't compile in 2005.

      The big advantage of open source licenses is that anyone can pick up some old open-source code which has been abandoned a few years back and make something useful out of it. Or would be able to, except for the fact that the people who write GCC continue to insist on breaking older code.

      I'm quite frustrated because I wasted hours trying to compile older code a few weeks ago and constantly hit a wall because of GCC's breakage.

      I think a well-written "How to fix things that don't compile" guide would be nice; I can usually make an educated guess and compile the code again, but obscure things like old-style variable-number-of-arguments code stump me.

      I think this is a general trend with some open source developers; they break code or configuration files without any regard for how much inconvenience they cause end users.

    4. Re:Why? by gaj · · Score: 2, Informative
      So you're saying that the smart developers over at Microsoft can't manage to code up support for new lanugage features themselves?

      While the standards compliance of pre-.net VC++ releases (and the C99 support of *any* VC++ releases) indicate that might well be the case, I'm inclined to think that it is not.

      I think it is much more sensable to conclude from your post that you are a) confused about the GPL, b) intentionally misrepresenting the situation, c) not the sharpest knife in the drawer or d) some combination of the above.

      Putting the gcc code under GPL doesn't put the language extensions under GPL.

  12. Autovectorization by QuantumG · · Score: 5, Interesting

    Correct me if I'm wrong here, but most Linux distributions are still i386 right? It's only the people who use Gentoo who actually compile everything with i686 options right? So, if autovectorization and all the other improvements in GCC 4.0 make binaries massively faster on modern platforms, how long will it be before the major binary based distributions (like Ubuntu) start making i686 the default and i386 an available alternative (like AMD64 is now).

    --
    How we know is more important than what we know.
    1. Re:Autovectorization by Dan+Berlin · · Score: 2

      Autovectorization is rarely going to make things "massively faster" for most applications. It just makes people feel better when they see their code is vectorized because they think it's cool. (Not that there aren't real applications for autovectorization, SIMD packing, etc. It's just not going to speed up OpenOffice, for example).

    2. Re:Autovectorization by QuantumG · · Score: 4, Interesting

      I used to work for Codeplay, a company that made compilers for games development, and we were pretty surprised at the kinds of speedups you would get on non-gaming applications. Obviously compiling open source software was a great way to test our compiler. Basically any loop which performs the same operation on multiple data can be unrolled 4 times and vectorized. That's a massive speedup. So yes, I would expect OpenOffice to be faster.

      --
      How we know is more important than what we know.
    3. Re:Autovectorization by Anonymous Coward · · Score: 4, Informative

      Most linux distributions being built for i386 is mostly incorrect and when not, a half-truth.

      Fedora Core, for example, relies on the improved instructions for atomic operations found in 486 and newer processors, necessary for certain threading libraries. The rpm program itself requires a 586, if I don't remember wrong.

      Fedora Core also compiles all binaries optimized for P4. It was decided to use P4 optimizations, since these generally work just as well on Athlon processors, while Ahtlon optimizations is rather slow on a P4.

      Furthermore, for CPU intensive applications such as many audio and video applications, CPU optimizations such as MMX and SSE are automatically activated at runtime if the CPU supports it.

      The 'i386' in the name should really be called 'x86'. Of course, then there's also 'i686' packages, which basically mean 'x86 processors that support the CMOV instruction'. That is also wrong, as there are i686 processors which do not support CMOV, such as certain VIA and Cyrix variants.

      CMOV is basically the only useful addition to the x86 instruction set since the i486 for general purpose programs. And programs not fitting into that category, already have hand written asm for time critical sections, which can take advantage of MMX, SSE, 3DNow, Altivec or VIS.

    4. Re:Autovectorization by mattdm · · Score: 3, Interesting

      Correct me if I'm wrong here, but most Linux distributions are still i386 right?

      Right in some ways, but importantly wrong in others. Red Hat and the Fedora Project, for example, are compiled using the i386 instruction set but optimized for i686. This means that the cmov instruction isn't available -- but apparently, it's not much of a win (and even a loss in some cases) on modern processors. And code which uses SSE or 3DNow or whathaveyou is usually carefully hand-coded and checked for at runtime.

      There's not really much advantage of switching away from this scheme, so I don't see it as worth the bother. Instead, x86_64 will eventually kill it all off and we'll move on to that.

    5. Re:Autovectorization by QuantumG · · Score: 2, Interesting

      You're like the 4th person to say that. The point of autovectorization is that all programs can benefit from SIMD instructions, not just the ones where programmers thought it might be a good idea.

      --
      How we know is more important than what we know.
    6. Re:Autovectorization by thalakan · · Score: 4, Informative

      Wrong. The SSE instruction set includes several instructions for doing vector integer ops, such as average and multiplication. These things are a huge speed win even in "average" applications, as the game compiler developer noted above. If you don't believe me, fire up a profiler and look at how much time an office app or web browser spends doing rectangle intersection calculations and TrueType font math.

      Also, there aren't nearly enough people using MOVNTDQ to avoid polluting the instruction pipeline and dumping useless garbage into the system cache. If you're copying stuff into main memory and you aren't going to use it for a while, use MOVNTDQ to get a big speed win. If you do need it cached, use MOVDQA to get both caching and 128 bit transfers in one instruction! We all paid for these fancy schmancy new instructions in our processors, and it's extremely annoying to see programmers not use them.

      --
      -- thalakan
  13. Figured this had to happen by jtshaw · · Score: 4, Interesting

    When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.

    1. Re:Figured this had to happen by k98sven · · Score: 5, Informative

      When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.

      Well, you're wrong because GCC doesn't follow Apple's schedule, or anyone else's for that matter. Even a cursory glance at the GCC mailing list will tell you that.

      The reason Apple can promise this is that they're not actually shipping GCC 4. They're shipping their own fork of the GCC 4 code. It's probably about 99% the same code, but don't make the mistake of thinking they're shipping exactly what the FSF is distributing.

    2. Re:Figured this had to happen by As+Seen+On+TV · · Score: 3, Interesting

      If anybody was wondering, this is why we stay as far away from the Gnu people as humanly possible.

      We're not shipping "a fork" of GCC 4. We're shipping GCC 4.0.0, which we compiled from source for Darwin 8.

      In fact, when you're talking about shipping a compiler for a specific platform, the whole notion of "a fork" is basically meaningless.

      (Setting aside, of course, that the whole notion of "a fork" runs 100% counter to all that open-source stuff that you guys are supposedly so hip to anyway.)

    3. Re:Figured this had to happen by dvdeug · · Score: 5, Informative
      We're not shipping "a fork" of GCC 4. We're shipping GCC 4.0.0, which we compiled from source for Darwin 8.

      According to http://gcc.gnu.org/install/specific.html#powerpc-x -darwin,
      The version of GCC shipped by Apple typically includes a number of extensions not available in a standard GCC release. These extensions are generally for backwards compatibility and best avoided.

      i.e. you're using a forked version of GCC, and definitely not 4.0.0 out of the box.

      the whole notion of "a fork" runs 100% counter to all that open-source stuff

      No, actually, the importance of the ability to fork and wisdom to know when to fork is very important to "that open-source stuff".
    4. Re:Figured this had to happen by As+Seen+On+TV · · Score: 3, Interesting

      You're defining "fork" so broadly that every build from every vendor would meet it. That's pretty silly.

    5. Re:Figured this had to happen by Anonymous Coward · · Score: 3, Informative

      Every build from every 3rd party DOES constitute a fork.

      Wrong.

      A fork is a branch from the primary codebase of ANY size.

      No, a fork is where a second set of developers take the original codebase at one well-defined point and use it as the base for their own project.

      OpenBSD and NetBSD are forks of the original BSD because they have taken the BSD code and turned it into their own divergent systems, both based on the same base but heading in different directions. A Linux kernel with one of the various non-Linus patchsets applied is not a fork, because the "non-standard" part is utterly dependent on the main kernel sources.

      Apple's GCC builds fall into the latter category, and therefore do not constitute forks.

      I repeat: Red Hat have not forked the Linux kernel, and therefore Apple have not forked GCC.

  14. *chuckle* by fr2asbury · · Score: 5, Funny

    I can see my Gentoo box sweating now all nervous for the night I get a little drunk and decide to see how this gcc 4 thing works out. heh heh heh.

  15. Re:Great Timing by Anonymous Coward · · Score: 2, Informative

    It's not a snapshot though, it's a fork (from that date). Apple has done some development on it.

  16. src tarball link? by codergeek42 · · Score: 2, Insightful

    Why didn't the poster just link to a list of mirrors? I don't want my favorite compiler's source to be unavailable =(

  17. Compatibility? Linux testing? by H0p313ss · · Score: 4, Interesting

    Just about every time I have to rebuild a kernel or build a kernel mod I get my butt kicked by gcc versions. So my questions are?

    • Are there compatibility issues with existing binaries?
    • What does this do to existing code?
    • How will this effect existing distros?
    • Is any distro planning on supporting 4.X soon? (And is that a good thing or a bad thing?)

    Anyone know?

    --
    XML is a known as a key material required to create SMD: Software of Mass Destruction
    1. Re:Compatibility? Linux testing? by SuperQ · · Score: 4, Informative

      Fedora Core 4 is GCC 4.0

  18. Re:Testing the old girl out... by Anonymous Coward · · Score: 4, Informative

    I can't wait to figure out what will (won't?) build with GCC 4.0.0. (One thing's for sure... JDK and OOo won't.)

    FYI: Red Hat has a guy working full-time on building OOo on GCJ. His blog.. Not that everything works straight out-of-the-box. But it's not like nothing works either.

    (And from what I've heard, you can't expect it to work out of the box either. Sun's coders have done a terrible job and adding all kinds of dependencies on undocumented Sun-internal classes. So it probably doesn't work on Apple's JDK either, and that one is Sun-approved!)

  19. Misplaced blame by tepples · · Score: 4, Insightful

    Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?

    At least the maintainers of the ISO C++ standard did.

    GCC motto: "What code can we break today?

    Blame the standards committee, not the GCC maintainers.

    1. Re:Misplaced blame by Screaming+Lunatic · · Score: 4, Funny
      Blame the standards committee, not the GCC maintainers.

      Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.

    2. Re:Misplaced blame by Mancat · · Score: 5, Funny

      Mechanic: Sir, your car is ready.

      Customer: Thanks for fixing it so quickly!

      Mechanic: We didn't fix it. We just brought it up to standards. Oh, by the way, your air conditioning no longer works, and your rear brakes are now disabled.

      Customer: Uhh.. What?

      Mechanic: That's right. The standard refrigerant is now R-134A, so we removed your old R-14 air conditioning system. Also, disc brakes are now standard in the autmotive world, so we removed your drum brakes. Don't drive too fast.

      Customer: What the fuck?

      Mechanic: Oh, I almost forgot. Your car doesn't have airbags. We're going to have to remove your car's body and replace it with a giant tube frame lined with air mattresses.

      --
      hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
    3. Re:Misplaced blame by IntergalacticWalrus · · Score: 4, Insightful

      Your analogy is thoughtful but flawed. Unlike compilers, automobiles aren't built PRIOR to the solidification of their standards of manufacturing (yeah, thank God for that).

    4. Re:Misplaced blame by Alioth · · Score: 3, Insightful

      So basically the GCC developers are damned if they do, damned if they don't - if they fix their bugs to make their compiler ISO C++ compliant, they are whined at for following the standard, if they preserve the bugs, they are whined at for not following the standard!

      Personally, I prefer GCC to be standards compliant.

    5. Re:Misplaced blame by Screaming+Lunatic · · Score: 3, Funny
      Blame the standards committee, not the GCC maintainers.
      Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.

      Funny? Jesus eff-ing Christ. When did pointing out the hypocricy of slashdot group think become funny? I don't get which part of my original statement is funny.

  20. Re:Great Timing by Tharkban · · Score: 2, Informative

    Fedora Core 4 has literally been waiting for this.

    From Feburary: http://lwn.net/Articles/124798/

    That article includes the question/answer:
    - Does that mean Fedora Core 4 will ship with a pre-release compiler?
    We're not *that* crazy. If GCC 4.0 is delayed, we will either revert, or slip.

    --
    Tharkban (It is a signature after all)
  21. get it while it's hot by cstacy · · Score: 2, Funny

    Hurry up and download your copy now, before the price goes up!

  22. Readme.SCO by karvind · · Score: 5, Interesting
    The gcc tar ball has a README.SCO file (reproduced below)

    The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software and GNU/Linux. We have decided to take no action at this time, as we no longer believe that SCO is a serious threat.

    For more on the FSF's position regarding SCO's attacks on free software, please read:

    http://www.gnu.org/philosophy/sco/sco.html

    1. Re:Readme.SCO by kernel_dan · · Score: 2, Informative

      http://www.gnu.org/philosophy/sco/sco.html

      SCO is so not a threat they decided to delete the page. (404 Not Found)

      oh, wait. here it is

      --

      Illegal? Samir, This is America.
    2. Re:Readme.SCO by NutscrapeSucks · · Score: 3, Interesting

      Maybe someone can find it, but the SCO GCC guy posted on Slashdot once. He indicated that he was pretty much single-handedly responsible for the SCO UNIX port, so GCC pulling their endorcement wouldn't make much if any difference to SCO customers. I belive his attitude towards his employer was "I don't like it but who else will pay me to hack on GCC?"

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
  23. gcc -v on Fedora 4 test 2 by hey · · Score: 3, Informative

    % gcc -v

    Using built-in specs.
    Target: i386-redhat-linux
    Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --host=i386-redhat-linux
    Thread model: posix
    gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)

    1. Re:gcc -v on Fedora 4 test 2 by no-karma-no-worries · · Score: 5, Funny


      > gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)

      aren't they supposed to release a broken 3.96 first???

  24. how much java comaptibility by b17bmbr · · Score: 3, Interesting

    i am interested in the java compatibility. i figure it probably won't do swing, but will it support, or is will it do say gtk/java native. that'd be sweet. i know Qt/kde has had a java bridge for a while, but i really haven't played to much with it. flame java all you want, it's not a geek language. no obfuscated java, no java monks. BFD. sure that'd nix the whole write-once run anywhdere thing. but hell, what a great opportunity to build and test apps under a jre then compile them, to native.

    --
    My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
    1. Re:how much java comaptibility by 0x000000 · · Score: 2, Informative

      RTFM. It says right in the changelog that more swing has been added.

      "There have been many improvements to the class library. Here are some highlights:
      Much more of AWT and Swing exist.
      Many new packages and classes were added, including java.util.regex, java.net.URI, javax.crypto, javax.crypto.interfaces, javax.crypto.spec, javax.net, javax.net.ssl, javax.security.auth, javax.security.auth.callback, javax.security.auth.login, javax.security.auth.x500, javax.security.sasl, org.ietf.jgss, javax.imageio, javax.imageio.event, javax.imageio.spi, javax.print, javax.print.attribute, javax.print.attribute.standard, javax.print.event, and javax.xml
      Updated SAX and DOM, and imported GNU JAXP"

      http://gcc.gnu.org/gcc-4.0/changes.html

      --
      cat /dev/null > .signature
  25. Something fun with compiling... by phoenix.bam! · · Score: 5, Funny

    and no gentoo users commenting on how they've already recompiled their entire system with the new optimizations. Or maybe they're just waiting for some free resources to open a browser.

    1. Re:Something fun with compiling... by Anonymous Coward · · Score: 2, Informative

      Nice troll. Good thing you know nothing of what your talking about. Any knowledgeable Gentoo user who uses Gentoo for optimizations alone will set it to recompile overnight, so when they wake up (provided the system isn't a P-II and they aren't running KDE), it should be done. It usually is for me on new installs. For everyone else who uses Gentoo, GCC 4.0 is just another compiler. I use Gentoo because of the minimalism it provides. I also use it because I can strip it down to the bare minimum much easier than most other RPM or DEB based distributions. I used to use Gentoo for the 'Rice' effect. Now I use it because the package management system, and the fact I can make a lean system which runs on 25MB of RAM, especially for those old NEC laptops I've been given by my school. And as for resources? Portage is automatically set at a high Nice, meaning that every other application, such as Firefox, has priority over it. If you're going to troll, at the very least know what your talking about.

  26. Objective-C++...? by Dimwit · · Score: 3, Interesting

    They've been talking about having Objective-C++ in the GCC main branch for years now. There was even talk that 4.0 wouldn't ship without it. Now it's shipped without it and it's still "coming Real Soon Now". Any word on if it's coming any time soon (really)?

    --
    ...but it's being eaten...by some...Linux or something...
    1. Re:Objective-C++...? by As+Seen+On+TV · · Score: 3, Informative

      Hmm. That's a pretty sound misrepresentation. You make it sound like our guys are spread too thin to work on Objective-C++. Not so.

      Fact is, demand for Objective-C++ from our developers is so close to zero as to be completely insigificant. Seriously, there's more demand for Python than Objective-C++. Honest to God, Python!

      All the ISVs who are still using C++ are building their apps with Core Foundation, not with Cocoa. That's fine. Core Foundation is a first-class application platform in Mac OS X. It's just so much more of a pain in the ass to use, developers are flocking away from C and C++ to reimplement in Objective-C, not even bothering with Objective-C++ along the way.

      So it's not that we don't have the time. It's that we don't see the point.

    2. Re:Objective-C++...? by framerate · · Score: 4, Interesting

      "All the ISVs who are still using C++ are building their apps with Core Foundation."

      No they're not! And I myself am not about to port hundreds of thousands of lines of C++ code to Objective-C since that'd eliminate the Windows version, which I can't do!

      In the code base I'm currently porting to Cocoa, all of the application's core logic and data structures are written in C++, and the user-interface layer is written natively for each platform. So the Mac version gets a high-quality Cocoa front-end and Windows/Linux/BSD gets a wxWidgets front-end (since wxWidgets does a good job on those platforms).

      Take away Objective-C++ (and therefore Cocoa C++) support and I'll just compile the wxWidgets version for the Mac since CoreFoundation is, as you say, a pain in the ass to use. The result: another low-quality "Windows-app-in-Aqua-clothing" Mac app.

      Cross-platform toolkits, such as wxWidgets, SWT and Swing produce usable but low-quality Mac applications (missing sheets, drawers, collapsable toolbars, AppleScript support, and so on and so forth). Objective-C++ allows me to easily write high quality Aqua-compliant applications easily. So if Apple values Mac users it will keep supporting Objective-C++!

      Not to mention that, for me at least, Cocoa/C++ is one of the reasons I use a Mac in the first place. I can produce professional user interfaces in no time and still know that I can port the core logic to Windows/Linux/BSD.

      Oh, and I'm working in the games industry, where the majority of code is C++. I know for a fact that Apple wants more games code ported to OS X.

  27. Re:What a coincidence by Anonymous Coward · · Score: 5, Informative

    The parent poster is refering to the deprecation of Managed Extensions for C++ syntax in favor of C++/CLI (which is undergoing ISO standardization).

    While it is true the syntax has changed (much for the better: templates are now supported in managed C++ code and so are generics, keywords replace ugly __gc, and more), support for the old syntax is still in the compiler (/clr:oldSyntax), and IntelliSense.

    However, you will be unable to mix new syntax and old syntax code in the same project without taking some penalties (IntelliSense will break, at the least). The designer will even spit out old syntax code when designing an old form or control.

    While the old syntax is definitely on its last legs, the VC++ team was very concerned about not screwing over those (early) adopters of C++ code for the CLR thus far.

    A good resource to read up more on the subject would be Herb Sutter's Blog, Stan Lippman's Blog, or any of the other VC++ team member's blogs.

    Take this from a former VC++ teammate who left during the Whidbey product cycle (posting AC since I've never bothered to get a slashdot account).

  28. Screenshots? by mrcrowbar · · Score: 5, Funny

    Screenshots anyone? ;)

    1. Re:Screenshots? by Herr_Nightingale · · Score: 4, Funny

      check OSnews.com for the screens. apparently it's not user-friendly enough yet, and the fonts aren't spaced correctly. Expect eugenia's appraisal and some "how it should be done" mockups shortly.

    2. Re:Screenshots? by peterpi · · Score: 2, Funny
      gcc: no input files
  29. just when OpenBSD i386 started to move to 3.x by ArbitraryConstant · · Score: 2, Interesting

    The OpenBSD crowd had a lot of concerns about bugs in 3.x and performance regressions (in compiling, not in the resulting binaries). I believe Linus shared some of these concerns (don't have a link handy).

    OpenBSD i386 is finally moving towards gcc 3.x, as the bugs have been cleared up even if the performance regressions haven't. I'm wondering if 4.x will be even worse, and if it will be justified by producing better binaries. From TFA, it looks like they've added a few features that may improve optimizations. If it's noticeably better they may move to the new version faster.

    I will have to play with it to see what it can do.

    --
    I rarely criticize things I don't care about.
    1. Re:just when OpenBSD i386 started to move to 3.x by lintux · · Score: 2, Interesting

      The story about bad performance of GCC 3.x is completely true. I myself wondered some time ago why my dual P3-550 was hardly faster at compiling kernels, compared to my old single P2-350. Actually, if there was only one P3 in it it would've been slower! (And yes, the machine had more RAM...)

      After a while I found out that the P2 ran Debian Woody with gcc 2.95 used by default and the P3 ran testing with gcc 3.3 (?) used by default. Another compile with the same gcc versions gave better results.

  30. vectorization very rarely works by vlad_petric · · Score: 4, Insightful
    The main problem is the C language. While vectorizing a loop is generally not that difficult, figuring out if it's the right thing to do is extremely tough. To do that, you have to "prove" that iterations of a loop are independent of each other. This, in turn, requires good pointer alias analysis, and gcc isn't doing it well enough yet. BTW ... a language like Fortran, that doesn't have pointers at all, is much easier to vectorize; that's one of the reasons a lot of scientific codes are still in Fortran.

    Without automatic vectorization, the performance benefit of compiling for 686 as opposed to 386 is simply minimal. A lot of people have done benchmarks on this, and found out that tuning for 686 with gcc only provides 1-2% improvements in the best case. Keep in mind that current X86 processors execute instructions out-of-order, so instruction scheduling for a specific pipeline is not going to do much (it's very important for in-order machines, though)

    --

    The Raven

    1. Re:vectorization very rarely works by drmerope · · Score: 2, Informative

      > A lot of people have done benchmarks on this,
      > and found out that tuning for 686 with gcc only
      > provides 1-2% improvements in the best case.

      Uh what? It is true that i386 code runs in the ballpark on a Pentium IV, but this most definitely was not true for the Pentium III and is not true for the Pentium M. Those processors have the 4-1-1 rule, which is to say that you'll stall concurrent execution of instructions unless you arrange a complex instructions (4) with two simple ones (1). This is because there aren't enough execution units to handle any kind of instruction.

    2. Re:vectorization very rarely works by Anonymous Coward · · Score: 2, Informative

      What is it that possesses people to post authoritative comments on Slashdot, about subjects which they know little to nothing about?

      The changes between 386 and 686 in instruction sets alone make optimizing for specific platforms more than worth it. In fact, at the performance lab at [big chip manufacturer where I work as an electrical engineer], we have observed as much as a 43% speed gain in compiled applications using a platform-optimized compiler!

      Granted these optimizations would be compiler-specific, and were obviously not made using GCC. However, your assertion that "tuning for 686 with gcc only provides 1-2% improvements in the best case" is simply absurd. Please get a clue before you post nonsense.

    3. Re:vectorization very rarely works by vlad_petric · · Score: 2
      Dear AC afraid of an NDA,

      I was talking about gcc, and gcc alone. After all, this is a story about gcc 4.0. I'm very well aware that compilers like icc are more capable of exploiting differences between old processors and newer ones. It's just that gcc is not. Please show me one single benchmark -- from a respectable suite, not something concocted to prove a point, and not something that has inlined assembly -- where tuning for 686 in gcc gives more than 5% performance improvement! My very strong belief is that the whole Gentoo "ultra-optimization" is simply a myth, because gcc is incapable of exploiting the differences.

      And if you bothered to do a little bit of googling, you'd have figured out that I'm not exactly foreign to computer architecture.

      --

      The Raven

    4. Re:vectorization very rarely works by gowen · · Score: 2, Informative
      BTW ... a language like Fortran, that doesn't have pointers at all
      Fortran 90/95 has pointers, just not in the C-like "It's an address of a chunk of memory" kinda way. Basically, they're pointers done properly, specifically designed to be limited in scope (they can only point at something declared to be a TARGET, for example) and they contain enough extra information to faciliate exactly the sort of opimisation you're talking about.
      --
      Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
  31. OOo Calc by tepples · · Score: 2, Interesting

    Sure, OpenOffice.org spends a lot of time at the idle loop compared to say Half-Life, but there are some cases when even a word processor can lag. Faster loops make repeated operations on the most complex documents, such as Writer reflow, Calc recalculation, and Draw repainting, faster. Faster operations make OOo more responsive in general. More responsive OOo makes users happy.

  32. GCC 4.0's biggest winner is probably KDE by Anonymous Coward · · Score: 5, Informative

    due to the fact that all its c++ shared libraries will now be 40% smaller due to the symbol visibility improvements (i.e., no runtime adjustment needed by the linker for internal-only functions). This translates into a significant speed improvement for all KDE code.

    1. Re:GCC 4.0's biggest winner is probably KDE by Anonymous Coward · · Score: 2, Interesting

      speed improvement for kde code? less symbols means dynamic linking is quicker, this is done at app startup, and does not effect running speed of the code at all.

    2. Re:GCC 4.0's biggest winner is probably KDE by Anonymous Coward · · Score: 5, Informative

      In case you hadn't noticed, the "slow" part of running KDE are the start up times. Once you actually get KDE loaded, the runtime speed is fine.

      -a GNOME/KDE agnostic fluxbox user

    3. Re:GCC 4.0's biggest winner is probably KDE by Taladar · · Score: 2, Funny

      The slow part of KDE is the compile time...

    4. Re:GCC 4.0's biggest winner is probably KDE by multipart · · Score: 2, Insightful

      Well, it's a shame then, that GCC 4.0 cannot even compile KDE. It miscompiles it.

    5. Re:GCC 4.0's biggest winner is probably KDE by Anonymous+Brave+Guy · · Score: 2, Funny
      The slow part of KDE is the compile time...

      Damn. You have to compile it? No wonder mine hasn't loaded yet...

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  33. Any bechmarks by DesiVideoGamer · · Score: 2, Insightful

    Does anybody have some informal performance benchmarks between 4.0.0 and the last version? (particularly the runtime of the application)

    1. Re:Any bechmarks by devnullify · · Score: 2, Informative

      The OpenSSL speed suite is about 2.87% (averaged over all of the throughput tests) faster with gcc 4 (Debian prerelease) than gcc 3.3.5 on my Duron machine. There were no cases where gcc 4 was more than 0.5% slower than 3.3.5.

  34. Patent issues by plgs · · Score: 5, Informative
    "Unfortunately we cannot implement Steensgaard [pointer] analysis due to patent issues."

    They mean this patent owned by this company. What a surprise.

  35. Getoo forum thread on gcc 4 by vandan · · Score: 3, Informative

    For those who want to know what works and what doesn't: http://forums.gentoo.org/viewtopic-t-176085.html

  36. Benchmarks comparing 3 to 4 available? by ivaldes3 · · Score: 2, Insightful

    Are there benchmarks comparing 3 to 4 available? What benefitw would the average user eventually expect from this release? Thanks!

    -- IV

    --
    http://www.LinuxMedNews.com Revolutionizing Medical Education and Practice.
  37. Re:stupid dumb moronic question by Analog+Squirrel · · Score: 2, Insightful

    As I understand it - and I'm sure someone will correct me when I'm wrong - gcc is actually a suite of language-specific "front ends" which reduces a given language to a common intermediate form that is then compiled(and linked, etc) by the "back end" into the executable code. In a way you already have different compilers... they're just all grouped together in one package.

    --
    I'd rather be flying
  38. You're right. by MrDomino · · Score: 2, Informative
    Like, could it conceivably work faster and use up less in the way of resources if the different languages were separated into different compilers?

    The different languages ARE separated into different compilers.

  39. Re:stupid dumb moronic question by noda132 · · Score: 3, Informative

    Does all this extraneous language support make gcc bloated for single-language compilation?

    Short answer: No.

    Long answer: pretty much every compiler around goes through the following steps: (a) make an abstract syntax tree from the source code, (b) optimize it, and (c) output machine code. No matter what language you're using, these steps must be performed; a multi-language compiler simply provides many ways of doing (a). But since optimization happens after (a) anyway, it doesn't matter.

    That's oversimplifying, since if a compiler were tuned to a single language it could probably use a slightly simpler abstract syntax tree format. But the benefits would be slight; it's far more useful to support tons of languages at little extra effort than to drop all alternate languages for a minor performance gain.

  40. people use -fweb by r00t · · Score: 2, Informative
    Having -finline-functions in -O3 is yucky. It tends to make code fall out of the cache, slowing things down. You get more cache misses.

    So the choice has been:

    • -O2 -fweb
    • -O3 -fno-inline-functions
    (adding -frename-registers or -fno-rename-registers too, as desired)
  41. Shouldn't they have done this 10 years ago? by Old+Wolf · · Score: 4, Interesting

    One of the changes in 4.0.0 is autovectorization optimizing.
    One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?

    Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.

    Sample code:

    int a[256], b[256], c[256];
    foo () {
    int i;

    for (i=0; i256; i++){
    a[i] = b[i] + c[i];
    }
    }

    1. Re:Shouldn't they have done this 10 years ago? by Hast · · Score: 2, Interesting
      One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?

      Because vectorisation and parallelisation are two very hard problems. Normal compiler optimisations pale in comparison for the most part.

      Even the best currently available vectorising compilers will do a pretty poor job compared to human optimisations (in cases where it's possible to do by hand). I have seen examples were a simple c-loop could be hand optimised into half a page of asm where a vectorising compiler produced 4 pages.

      It is a REALLY hard problem.

      Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.

      Which leads me to believe that it wasn't doing a very good job at all. Just because it claims to do vectorisation and adds a few asm instructions doesn't mean it's doing a poor job. That they couldn't even detect the iterator variable may even hint that it could produce broken code.
  42. Re:Wishing you could shoot the dog by BurnFEST · · Score: 2, Funny

    That game was gold. And I too wish you could shoot the dog.

  43. Example by TeknoHog · · Score: 3, Interesting
    For an example of a sensible (slightly higher-level) language, consider the Fortran example from the autovectorization page:

    DIMENSION A(1000000), B(1000000), C(1000000)
    READ*, X, Y
    A = LOG(X); B = LOG(Y); C = A + B
    PRINT*, C(500000)
    END

    Notice the lack of an array index. These are true vector operations to begin with, so it is already assumed that the array elements are independent, therefore the log and addition can be parallelized safely.

    --
    Escher was the first MC and Giger invented the HR department.
  44. No hope for named warnings by 19thNervousBreakdown · · Score: 2, Interesting

    Will named warnings never be impemented? Or numbered? Something that lets me turn off a warning for a particular line of code?

    Have you ever tried writing an overflow safe integer class? I have, and I did, but I have to compile everything with -w because otherwise I get 40 pages of "condition will always be false due to limited range of data type". Bleh! If it will always be false, throw it away! I need the check in there for when the type will be a signed int.

    Does anyone have a ray of hope? I love most of GCC's warnings, and have always been able to work around them, but in this case there's just no way to get rid of them.

    --
    <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    1. Re:No hope for named warnings by prockcore · · Score: 3, Informative

      I get 40 pages of "condition will always be false due to limited range of data type". Bleh! If it will always be false, throw it away! I need the check in there for when the type will be a signed int.

      Maybe I'm missing something, but this warning is GCC telling you that it's not going to compile that code.. so you can't possibly "need" it because GCC doesn't even compile it.

      uint8_t i=0;
      if (i>300)
      {
      printf("hello");
      }

      Compile that, and then see for yourself.. strings a.out | grep hello will return nothing. gcc optimizes your useless check right out.

    2. Re:No hope for named warnings by 19thNervousBreakdown · · Score: 2, Informative

      Exactly, and that's what I want it to do, but it gets tricky when you're using templates...

      template <class T> class safeint {
      template <class FromT> safeint (FromT const number) {
      // I know this test will fail sometimes, it's just an example.
      if (number < numeric_limits<T>::min()) {
      throw "You stink!";
      }
      };
      };

      If FromT is an unsigned int, and T is an int, the check will never be true and should be optimized away. However, if it's the other way around, we need that check, or there can be overflow.

      Also, I'd like to have the warning only disabled for that one line of code, so that if I make a mistake elsewhere the compiler will help me find it.

      Visual C++ can do it, come on GNU!

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
  45. Re:"Paltry" is probably a poor choice of words by 1lus10n · · Score: 4, Insightful

    You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple). The vast majority of which use gcc or some derivative.

    Unix and its children and cousins on the back and front end probably double the total number of apple boxes out there. If not more so. Hell some numbers suggest that there actually are more linux desktops than mac desktops. Even if its close between apple and linux on the desktop (which is likely) the number of nix systems in use in general at least matches the number on either side (though they are not desktops).

    --
    "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
  46. Re:"Paltry" is probably a poor choice of words by AHumbleOpinion · · Score: 2, Insightful

    You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple). The vast majority of which use gcc or some derivative.

    My concept of numbers is probably fine. Try this, desktops dwarf servers and such. So your 50% of a small number is not all that meaningful. ;-)

  47. Gentoo with GCC 4 by Zan+Lynx · · Score: 2, Informative

    Gentoo has had a GCC 4 ebuild for months now. I've been using it to build my system. If you really really want it, you need to set your package.keywords to -* and also unmask it in package.unmask.

    Then be prepared to switch between gcc 3.4 and 3 a lot because many packages, especially multimedia packages, fail to build.

  48. Pascal by AmicoToni · · Score: 2, Interesting

    Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.
    They always seem to be close, yet it never happens.

    1. Re:Pascal by dvdeug · · Score: 2, Informative

      Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.

      GNU Pascal supports building with a number of versions of GCC, and work on GNU Pascal is with a released version of GCC. The GCC developers want GNU Pascal as just another frontend; changes should go to GCC head, and there shouldn't be #ifdefs to get it to compile with different versions of the compiler backend. That's a large problem that has stopped GPC from being merged.

  49. TR1 included! by Anthony+Liguori · · Score: 5, Informative
    I'm surprised noone's mention the inclusion of the C++ TR1. There's a ton of very cool new library features. Here are my two favorite:
    #include <tr1/functional>

    int foo(int x, int y) { return x * y; }

    using namespace std::tr1::placeholders;

    int main() {
    std::tr1::function<int (int, int)> f;
    std::tr1::function<int (int)> g;

    // f can be stored in a container
    f = foo;

    f(2, 3);

    g = std::tr1::bind(f, _1, 3);

    // this is equivalent to f(2, 3)
    f(2)
    }
    Not to mention the inclusion of shared_ptr which provides a reference counted pointer wrapper. This will eliminate 99% of the need to do manual memory management in C++. It's all very exciting, kudus to the G++ team on this!
    1. Re:TR1 included! by drac667 · · Score: 3, Informative
      TR1 means Library Technical Report 1, it contains:
      • std::tr1
      • Utilities
        • shared_ptr
        • regular expressions
        • random numbers
      • Meta-Template-Programming
        • reference_wrapper
        • lambda binders and adaptors
        • type_traits
        • tuples
      • Containers
        • arrays
        • hash containers
      For more information see this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1647.pdf
  50. Re:"Paltry" is probably a poor choice of words by As+Seen+On+TV · · Score: 4, Informative

    Let's say that Apple has 99.9999999% of all desktop installs. Even then, almost none of them actually use GCC.

    Mac OS X itself is compiled with GCC 4. That was the point. Hence, all Mac users depend on GCC 4. That's 40 million and counting according to the latest figures.

  51. MINGW? by Spy+der+Mann · · Score: 2, Insightful

    From what I've read, GCC 4 is blazingly fast, _AND_ provides dead code elimination (VERY important for windows users).

    So, any ideas of how long till the MINGW port is done?

    1. Re:MINGW? by cimetmc · · Score: 2, Informative

      According to the following link http://www.mingw.org/MinGWiki/index.php/TheNextRel ease it might still take some time before there will be an official new MinGW version. However unofficial versions tend to popup quite quickly. For instance the following web page http://www.thisiscool.com/gcc_mingw.htm regularly provides MinGW binaries for GCC snapshots.

      As for the speed of GCC, the compilation speed is often a bit disappointing compared to commertial compilers. Dead code elimination is an optimization which GCC already does for a very long time.

      Marcel

  52. Found it: ISO C standard, sections 5.2.1 and 7.9.2 by mccalli · · Score: 2, Informative
    Useful usenet posting about this here. Notice the date of the post: 1993.

    Cheers,
    Ian

  53. Re:Found it: ISO C standard, sections 5.2.1 and 7. by cuerty · · Score: 2, Informative

    I think that stuff like this made the GCC developers to add de -pedantic flag, from de man file:

    -pedantic
    Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++.For ISO C, follows the version of the ISO C standard specified by any -std option used.

    Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few will require -ansi or a -std option specifying the required version of ISO C).However, without this option, certain GNU extensions and traditional C and C++ features are supported as well.With this option, they are rejected.

    -pedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __.Pedantic warnings are also disabled in the expression that follows "__extension__".However, only system header files should use these escape routes; application programs should avoid them.

    Some users try to use -pedantic to check programs for strict ISO C conformance.They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all---only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.

    A feature to report any failure to conform to ISO C might be useful in some instances, but would require considerable additional work and would be quite different from -pedantic.We don't have plans to support such a feature in the near future.

    Where the standard specified with -std represents a GNU extended dialect of C, such as gnu89 or gnu99, there is a corresponding base standard, the version of ISO C on which the GNU extended dialect is based.Warnings from -pedantic are given where they are required by the base standard.(It would not make sense for such warnings to be given only for features not in the specified GNU C dialect, since by definition the GNU dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.)


    "pendantic" is a ironic way of call it.

    --
    >Linux is not user-friendly.
    It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
  54. Re:Still no C99? by m50d · · Score: 2, Interesting

    Is broken in some important ways, for example you can't pass complex numbers to functions, which is why it isn't the default

    --
    I am trolling
  55. Re:perl fork bug by hyc · · Score: 2, Informative

    ??? When an application calls fork() everything that happens next is up to the kernel. The definition of fork() is that the child gets an identical copy of everything. What does the compiler have to do with this?

    --
    -- *My* journal is more interesting than *yours*...
  56. the most important question by SQLz · · Score: 2, Funny

    Does this new GCC have a transparent background?

  57. Re:"Paltry" is probably a poor choice of words by halivar · · Score: 2, Funny

    Mac OS X itself is compiled with GCC 4.

    Amazing, considering it was just released. Maye Jobs has missed his true calling as a purveryor of time machines?

  58. Re:Slow code? by Anonymous Coward · · Score: 2, Funny

    That someonebody is me. Yes, the binaries from 4.0.0 compared to 3.4.3 are very very.

  59. Re:"Paltry" is probably a poor choice of words by A+nonymous+Coward · · Score: 2, Insightful

    No. Being the largest single vendor is not the same as being larger than all other vendors combined. Apple may be larger than RedHat, and larger than Mandrake, and larger than Slackware, and larger than Debian, but that doesn't make Apple bigger than all of them combined.

  60. Re:perl fork bug by tacocat · · Score: 2, Informative

    It's not supposed to fork the file pointer.

    Read data in from a 'while()' statement and store it into an array. When it reaches a certain size, fork the process, kill the array and start filling it up from STDIN. Next time you fork your data is partially duplicated in Solaris and not at all duplicated under Linux.

  61. Re:"Paltry" is probably a poor choice of words by Lars+T. · · Score: 2, Insightful
    You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple).

    The backend of the internet compared to the number of desktop machines? Talk about having no concept of numbers.

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  62. Re:"Paltry" is probably a poor choice of words by jusdisgi · · Score: 2, Insightful

    Mac OS X itself is compiled with GCC 4. That was the point. Hence, all Mac users depend on GCC 4. That's 40 million and counting according to the latest figures.

    No, no, and no, jackass! Max OS X Tiger was compiled with gcc 4. Hence all Mac users do not depend on gcc 4. That is not 40 million and counting...it is currently zero. Give it a rest!

    --
    Given a choice between free speech and free beer, most people will take the beer.