Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 4.9 Coming With Big New Features

Posted by timothy on from the holy-linkage-batman dept.

jones_supa writes "When GCC 4.9 is released in 2014 it will be coming in hot on new features with a large assortment of improvements and new functionality for the open-source compiler. Phoronix provides a recap of some of the really great features of this next major compiler release from the Free Software Foundation. For a quick list: OpenMP 4.0, Intel Cilk Plus multi-threading support, Intel Bay Trail and Silvermont support, NDS32 port, Undefined Behavior Sanitizer, Address Sanitizer, ADA and Fortran updates, improved C11 / C++11 / C++14, better x86 intrinsics, refined diagnostics output. Bubbling under are still: Bulldozer 4 / Excavator support, OpenACC, JIT compiler, disabling Java by default."

24 of 181 comments (clear)

  1. A big improvement indeed by Anonymous Coward · · Score: 3, Insightful

    New in this release: lots of stuff most people don't care about, some minor improvements and oh yeah we gave up on Java.

    1. Re:A big improvement indeed by cduffy · · Score: 4, Insightful

      You only don't care about sanitizing standard-undefined behavior if you don't care about bugs.

      That one's a Really, Really Big Deal.

    2. Re:A big improvement indeed by Anonymous Coward · · Score: 3, Interesting

      New in this release: [...] we gave up on Java.

      Well, actually it's the other way around: Java gave up on them - meaning that actual development of GCJ moved from GCC to OpenJDK.
      Not that i understand what it means for GCC, but i understand that it does not mean much for Java.

    3. Re:A big improvement indeed by DuckDodgers · · Score: 4, Interesting

      No, it is not. But GCJ Java-to-native compiling didn't result in particularly fast Java code. That's one of the major reasons developers and enterprises ignored GCJ in the first place.

    4. Re:A big improvement indeed by larry+bagina · · Score: 3, Funny

      I care. Or I will, in 5 years, when it's finally available in debian.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    5. Re:A big improvement indeed by Hizonner · · Score: 5, Insightful

      I assume you can list all the undefined behaviors in the C standard off the top of your head, yes? And you've never actually written a line of code with an error in it, right?

      I've spent a lot of time cleaning up after security bugs written by people with that attitude. None of them could make mistakes either. Maybe you guys should form a club, so the rest of us can identify the special beings walking among us.

    6. Re:A big improvement indeed by Anonymous Coward · · Score: 3, Interesting

      Frankly I neither know nor care if your perception is that you have spent a lot of time cleaning up after security bugs, but the fact that you don't understood what my attitude is makes it fairly implausible.

      For one thing, a lot of shops do not permit a drop into naked API calls, and areas of concern are often abstracted out. And even if they a developer and tests should be checking the documentation for that API. But that's all irrelevant. My point was that this is mainly useful on programs that already have flaws that should not be waiting either for Your Highness or gcc 4.9 to percolate into all of the used OSs.

      If a bleeding edge compiler release is relevant to your security NOW you have problems.

    7. Re:A big improvement indeed by Darinbob · · Score: 3, Interesting

      No one programs anymore. All we do is link together pre-built libraries and frameworks and wrap it all in XML. Not sure who actually codes those libraries or where they come from, but the prevailing theory is that once a year the senior developers hike to the top of Mount Olympus and wrestle them away from the gods.

  2. ADA? by Black+Parrot · · Score: 4, Informative

    "Ada" is the name of a person, and the language.

    "ADA" is the Americans with Disabilities Act, or the American Dental Association.

    --
    Sheesh, evil *and* a jerk. -- Jade
  3. Can we please stop mass-linking Phoronix? by Anonymous Coward · · Score: 5, Insightful

    For God's sake, that's *THIRTEEN* (13) links to Phoronix!
    Pointing to a couple of ML threads or to the 4.9 changelog would've been more than enough. http://gcc.gnu.org/gcc-4.9/changes.html

  4. Looks like they are porting Clang features... by gnasher719 · · Score: 3, Insightful

    The whole article really reads quite fanboyish / alternatively GCC has hired a marketing department. But it looks really lame when you talk about exiting new features, and you just copied what Clang had before.

    1. Re:Looks like they are porting Clang features... by Anonymous Coward · · Score: 5, Insightful

      Superior backend, coming up to par with Clang on the frontend, what's not to love?

      Frankly, the BSD licenses appear to be a failure psychologically. The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code, but are ok if the stuff disappears in proprietary forks.

      You can see this, for example, with LibreOffice/OpenOffice: every LibreOffice release announcement draws ire from the OpenOffice crowd (well, particularly one OpenOffice developer) because the latter feels their code has been ripped off.

      There has been a lot of that going on with OpenBSD and FreeBSD as well, but it's grown a bit more quiet in recent years.

      Now we have the same with Clang/GCC.

      If you don't want to have your code relicensed under different licenses, use a Copyleft license. If you want to have your code relicensed under different licenses, stop complaining when somebody actually does exactly that.

    2. Re:Looks like they are porting Clang features... by mvdwege · · Score: 4, Insightful

      Wait, what, Clang now supports other languages than C-derivatives, like Ada and Fortran?

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    3. Re:Looks like they are porting Clang features... by Anonymous Coward · · Score: 3, Interesting

      Yep. They're also stealing OMP4.0 from Clang (which got OMP3.1 just a month or so ago, while GCC had it since 4.7) and Cilk (which is not in Clang at all, though people are working on 3rd party extension)

      The whole post really reads quite trollish / alternatively Clang has hired black PR department.

    4. Re:Looks like they are porting Clang features... by DuckDodgers · · Score: 3, Insightful

      You are re-stating the original argument about free software that has been done to death on the internet.

      To the BSD folks, they want to write software that is free as in free beer. You can take it, and do whatever you want with it. Drink it, dump it in the trash, give it to your friends, sell it. Free as in Freedom of the user

      To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it. Just like I can't hand out a copy of the US Constitution or a speech by Abraham Lincoln and forbid other people from sharing it or publishing a copy. Free as in Freedom of the software

      You may prefer the BSD way, and that's fine, but "who isn't a zealot" is out of line. Having a different set of priorities does not make one a dick. Blatantly copying code under one license to the other is a dickish move, but re-engineering from one to the other is perfectly legitimate. And yes, I'm in the FSF camp.

    5. Re:Looks like they are porting Clang features... by gnasher719 · · Score: 3, Insightful

      To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it. Just like I can't hand out a copy of the US Constitution or a speech by Abraham Lincoln and forbid other people from sharing it or publishing a copy. Free as in Freedom of the software

      Yes, there is always the "free as in free speech" high horse, but the fact is that (a) you can't legally use GPL licensed code in a BSD project, and (b) when licensed code is moved to a BSD project and modified, you can't legally move the changes back to the BSD project.

      So these people's view of "free" is something that I can only call perverted.

    6. Re:Looks like they are porting Clang features... by Wootery · · Score: 5, Insightful

      The 2-clause BSD license (which is the one used nowadays) is 7 lines of natural English (excluding the disclaimer) and people still can't understand it...

      You can't take BSD code and change it's license.

      It's ironic that you're laughing at those who misunderstand the licence, given that you've fundamentally midunderstood the licence.

      If your interpretation were correct, it would be functionally comparable to the GPL, and we wouldn't have all those flame-wars.

      It's a 'copycenter' licence, not a copyleft licence. You're allowed to release your fork under your choice of licence, whether proprietary, Free/Open Source, or anywhere in between, provided you don't hide the fact that your software is based upon that original BSD 2-clause licensed software.

      It's a little confusing, as "must retain the above copyright notice" can easily be misinterpreted the way you did, to mean "you must release your fork under the BSD 2-clause licence".

      Relevant Wikipedia content.

  5. Re:Coming in 1024 sometime? by Greyfox · · Score: 3, Informative

    2014 is just a month and a half away, and you can compile 4.9 now from the dev branch of their subversion tree.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  6. But but Google? by iYk6 · · Score: 4, Insightful

    But then how would Googlebot know that Phoronix is really great and popular and they should rank it higher in searches?

  7. Finish C++11 support first? by joncombe · · Score: 5, Interesting

    I see from the status page the Regex support is still not complete, part of the C++11 standard. It would be nice if support for this standard could be completed before starting on C++14.

  8. Re:frist by StripedCow · · Score: 5, Funny

    finally

    C++0x does not have "finally".
    You'll have to implement it yourself, e.g. using a destructor.
    See for example: http://codereview.stackexchange.com/questions/2864/an-implementation-of-finally-in-c0x

    --
    If Pandora's box is destined to be opened, *I* want to be the one to open it.
  9. Re:GCJ vs. JIT by codealot · · Score: 3, Interesting

    1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.

    2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?

    3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.

    4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.

    Mostly I agree with your points. Especially that Perl is dog slow.

  10. Thank you, Clang by Urkki · · Score: 4, Interesting

    Clang has really become a boon to open source compiler development. Unlike the open source *BSD operating systems, which are too far behind the GPL operating systems in many measures (not all), Clang has really electrified the compiler scene.

    I see nothing but good things coming from this in near future.

    And in such a rapidly evolving area as compiler development, having a *BSD license does not really hurt either. It's not like the *compiler* is likely to get put into some device with proprietary modifications.

  11. Re:GCJ vs. JIT by bored · · Score: 3, Interesting

    I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?

    Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no. A number of machine emulators (CPU->CPU, see apple Rosetta) perform dynamic translation, and in a number of cases pretty advanced optimization. There have also been a number of native dynamic translators for a given machine architecture see (http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html) for one example. There are also strange hybrids like the Intel Profile Guided Optimizations, where the feedback from a particular run is used to statically recompile the code. This effectively removes the profile/recompile overhead from an application at the expense of the fact that its now statically optimized for a particular kind of dataset.

    But, you ask why isn't a JIT part of most compiler packages if it gives you all these advantages. And the answer is three fold. First OOO CPU's kill the majority of the advantage that projects like dynamo found. Secondly, the overhead of the dynamic translation monitoring/recompile is often greater than the performance gain. And finally, the JIT advantages are often isolated to small hot pieces of code (compared with optimizing an application that is hundreds of MB of code). Applications with small performance critical functions are often hand optimized in C/C++ languages in ways that cannot be done by simple dynamic optimization and often yield functions that execute at the maximum a particular piece of hardware is capable of (say limited by memory bandwidth, functional unit throughput, etc).