Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming GNU is Not Unix Open Source Software Upgrades

GCC 4.9 To See Significant Upgrades In 2014 191

Posted by Soulskill
from the it's-almost-2014 dept.
noahfecks writes "It seems that the GCC developers are taking steps to roll out significant improvements after CLANG became more competitive. 'Among the highlights to look forward to right now with GCC 4.9 are: The Undefined Behavior Sanitizer has been ported to GCC; Ada and Fortran have seen upgrades; Improved C++14 support; RX100, RX200, and RX600 processor support; and Intel Silvermont hardware support.'"
This discussion has been archived. No new comments can be posted.

GCC 4.9 To See Significant Upgrades In 2014

Comments Filter:
  • Perhaps it should be banged on a bit before worrying about 4.9.x as it takes a while before everyone starts using the bleeding edge gcc.
    • by Anonymous Coward on Sunday October 27, 2013 @01:25AM (#45249665)

      No. C++ in particular has resumed the rapid evolution it enjoyed long ago and GCC needs to keep up.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        No. C++ in particular has resumed it's crazy-ass changes that makes code from two years ago look obsolete

        FYFY. C++ will be the Fortran of our generation... twenty years from now everyone will be laughed at for touching C++, but it will have all of these nice libraries....

        • by epyT-R (613989) on Sunday October 27, 2013 @02:00PM (#45252605)

          Yeah, because those interpreted/bytecode 'point-and-stick' languages are the wave of the future right? Most of their interpreters are written in C++ too. Now we have applications that used to need 1MB in 1998 needing hundreds of MB of ram to do the same remedial things. Also, don't forget to add all the 'binding' dependencies needed to link that script-land with the real system libraries, which are also C/C++, so that it is actually useful. In most cases, a competent programmer can put together an equivalent program with a binary size less in the hundreds of kB using C/C++. It's smaller, faster, and has fewer dependencies and potential bugs because there's less code running in the first place.

          There will always be at least one 'bare metal' language around because we have to be able to write for the hardware, whether it be C/C++ or something else, and every programmer should be familiar with its basics at least.

          • by superwiz (655733)
            Yes, but if you don't know how to do it faster and clearer with an IDE, you are wasting your time and your employer's money.
        • by Yvanhoe (564877)
          I know better than to laugh at Fortran developpers.
    • by Anonymous Coward on Sunday October 27, 2013 @03:01AM (#45249861)

      What's your point? 4.8.2 is the second bugfix/stabilization release of 4.8.0 which was released in March this year. Should they stop releasing bug fixes as soon as they start developing the next generation compiler? Should they refrain from any new developments until the old version has proven to be bug free?

      What's wrong with continuing development that will likely result in a new version release next year?

      • by gweihir (88907) on Sunday October 27, 2013 @06:41AM (#45250389)

        My guess would be that some people just do not understand how release numbers work...

      • Don't get me wrong: it's good that gcc continues its development, even if some of it was spurred only by the comparisons with clang,

        It's just that I'm sceptical about the news value of what gcc is *planning* to do next year. It's nice to hear that they actually have a road map, but I think that a thorough evaluation of what they have actually released would be more interesting.

        E.g. a thorough and up-to-date comparison of gcc object code quality, quality of optimisations, quality of vectorisation, clarit

    • by CurryCamel (2265886) on Sunday October 27, 2013 @08:35AM (#45250761) Journal

      Strange - everyone is constantly using the bleeding edge Clang, as a new version is popped out every six months, and nobody is complaining about that (loudly, at least). Just try and file a bug against last year's clang, and the first question asked is "does it work on 3.3?". If it does, that bug is closed, with no more thought to it.

      If LLVM can (quoting the insert) surpass GCC with this release method, then why should GCC not adapt a more rapid pace to accomodate contemporary fashions in opensource? Adapt or die.

      BTW, has anybody else noticed the change in time? Way back when, GPL:ing your compiler was the right thing to do, forcing it to be open source. This way GCC devs knew improvements would be fed back to the main line. But nowdays (I argue), LLVM's more liberal license is giving it an edge in the way industry is taking an interest. LLVM/Clang is becoming the "obvious" choice when developing a custom compiler, as you don't have to contribute your stuff to mainline LLVM.
      But the rapid pace of LLVM makes it actually cheaper to do so, due to lesser maintenance costs. Because your custom compiler you sell your clients is certainly not versioned against the current source tree, forcing you to jump through hoops backporting bugfixes from old LLVM snapshots.
      This makes LLVM getting the same improvements as GCC would get due to the license issue due to a carrot, not a stick. While still keeping the PHBs happy because of the license.

      • LLVM was offered for next gen GCC, it's author has nothing against GPL ... in the end patches from people extending LLVM do very little compared to the $$$ Apple contributes to it's development (of course Apple does have something against the GPL).

      • by tlhIngan (30335)

        BTW, has anybody else noticed the change in time? Way back when, GPL:ing your compiler was the right thing to do, forcing it to be open source. This way GCC devs knew improvements would be fed back to the main line. But nowdays (I argue), LLVM's more liberal license is giving it an edge in the way industry is taking an interest. LLVM/Clang is becoming the "obvious" choice when developing a custom compiler, as you don't have to contribute your stuff to mainline LLVM.

        No, what happened was the GPLv3 has spooke

      • Just try and file a bug against last year's clang, and the first question asked is "does it work on 3.3?". If it does, that bug is closed, with no more thought to it.

        If they already fixed it, why would they want to put any more thought to it?

  • by MichaelSmith (789609) on Sunday October 27, 2013 @01:40AM (#45249707) Homepage Journal

    Perhaps in json?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      How can the compiler be more sparkly?

      Can it compile directly to my 3D printer?

      Does it output rainbows and unicorn farts?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Parsable output is the root of all Evil I tell you, it allows proprietary software (yuck) to interface with FREE software. That is bad and cannot be allowed.

      GCC has a history of convoluted design and a disdain for well defined interfaces to make use with non-free hardware harder. Parsable output would allow you to completely bypass the GPL, so this is never going to happen in the flagship GNU project.

      • Yeah, I thought the big thing about clang aside from being newer is that it isn't GPL.
      • Nuts. I just want to display meaningful compilation results when I compile from within nedit.

      • by smash (1351)
        It also enables free software to interface with free software.
        • Say you have a product that you're distributing as free software, but it's of such quality that it doesn't need much paid technical support. So how do you cover the cost of keeping a roof over your head while you develop this product?
  • by jones_supa (887896) on Sunday October 27, 2013 @07:02AM (#45250471)
    There's an interesting Clang talk at Channel9: The Care and Feeding of C++’s Dragons [msdn.com]. Speaker: Chandler Carruth, Clang lead, Google.
    • by loufoque (1400831)

      That description is ambiguous. Chandler's isn't the "Clang lead". He's the guy that leads Google's developments in Clang.
      The main developers of both Clang and LLVM are from Apple.

"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"

Working...