Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 4.9 To See Significant Upgrades In 2014

Posted by Soulskill on 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.'"

8 of 191 comments (clear)

  1. 4.8.2 is not even 2 weeks old by SpaceLifeForm · · Score: 1, Interesting

    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.

    --
    You are being MICROattacked, from various angles, in a SOFT manner.
    1. Re: 4.8.2 is not even 2 weeks old by loufoque · · Score: 4, Interesting

      I thought I was the only one with the performance problems. No one seems to care about my bug reports. Most of the overhead seems to come from the new macro tracing feature, by the way.

      For C++ programming you'll need GCC 4.8 anyway because there is no way to get a complete template trace with 4.6 or 4.7. I don't understand what thet were thinking when they decided to skip arbitrary instantiation contexts in the trace with no ability to not skip them.

    2. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · · Score: 3, Interesting

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

    3. Re:4.8.2 is not even 2 weeks old by CurryCamel · · Score: 4, Interesting

      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.

  2. Re:Biggest boon to GCC: lack of hackability by serviscope_minor · · Score: 5, Interesting

    ...which is exactly why some folks are flocking to CLANG.

    People are flocking to CLANG for a variety of reasons. A large part seems to be because for some reason the GNU tools have become deeply unfashionable.

    LLVM has some structural advantages (due to being youger), but despite that all, GCC is comfortable keeping ahead of CLANG in both the optermizer and C++ support, so it cant be that bad.

    Sure, not everyone wants to extend/modify his compiler, but actively preventing people from reusing your code isn't exactly what you should do if you want to keep a community thriving.

    RMS is but one voice on the steering committee. He can say what he wants (and does), but the committee doesn't have to listen.

    That sad, when taking the long term into account, his whacky ranting and raving has the sad tendency to come true.

    --
    SJW n. One who posts facts.
  3. Re:GCC still has a long way to go... by gweihir · · Score: 4, Interesting

    With some insight into how some people write real high-quality enterprise grade software, I can confidently state that you are completely clueless. In addition, many enterprises that are critically depending on IT infrastructure are now considering replacing Solaris with Linux (RHEL typically), due to problems with basically _everything_ Oracle makes. And of course the most critical part of RHEL (the kernel) is compiled with GCC.

    You are suffering from the common misconception that things you pay for are better. Psychologically well researched, but it does not hold up in reality, and is just a specific form of stupidity, i.e. ignoring reality to take comfort in your own misconceptions.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  4. Re:Quality by TheRaven64 · · Score: 3, Interesting
    That's a crazy misrepresentation. The Phoronix article is mentioning the fact that clang now enables the autovectorisers at -O2, but it doesn't cover the reason for the switch. -O2 is intended as the default optimisation level for release builds. It should (almost) always produce faster code than -O1 or -O0, at the cost of greater compile times. Enabling an optimisation at that level means that it's unlikely to cause slowdowns. In 3.3 and in GCC, the autovectoriser can create larger code and more vector-scalar register copies that cause a slowdown that offsets the speedup from using the vector ALUs. As such, they're only run if explicitly enabled, so you people with performance-critical code can test them and see if they actually do provide a speedup.

    As to the quality of the error messages, I recently fixed a number of bugs in some third party code that were raising warnings with clang. One warning, that a comparison was the result of a comparing an unsigned value as being less than zero, occurred in four string processing loops in the code. In each case, it was iterating over characters in a user-provided string and appeared to be a security hole. Fixing it was trivial (change the type to a signed integer), but I like it when my compiler points out serious bugs in code that I'm compiling.

    --
    I am TheRaven on Soylent News
  5. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · · Score: 2, Interesting

    >GCC is comfortable keeping ahead of CLANG in both the optermizer and *C++ support*, so it cant be that bad.
    Um. No it isn't. Clang finished c++14 support a few weeks ago. Dev builds of gcc aren't there yet.