Results 1 to 9 of 9

Thread: GCC 4.9 Diagnostics Will Begin Playing With Colors

  1. #1
    Join Date
    Jan 2007
    Posts
    14,810

    Default GCC 4.9 Diagnostics Will Begin Playing With Colors

    Phoronix: GCC 4.9 Diagnostics Will Begin Playing With Colors

    While GCC 4.8 was released less than two months ago and GCC 4.9 isn't likely to surface until 2014, there's already a new feature to the next major update of the GNU Compiler Collection. GCC 4.9 introduces support for colored outputs in debugging...

    http://www.phoronix.com/vr.php?view=MTM2MzI

  2. #2
    Join Date
    Apr 2008
    Posts
    163

    Default Origin of colour ?

    Quote Originally Posted by phoronix View Post
    GCC 4.9 introduces support for colored outputs in debugging
    Well, technically colour output in GCC has been available for ages, thanks to tools like colorgcc - which post-processed and colorized gcc/g++ messages (actually since even before someone start to think about creating llvm), but were a 3rd party separate layer/wrapper ( la distcc, ccache, etc.)

    The novelty, as far as I've understood, is that GCC is baking better support for error-reporting directly into core GCC itself, by exporting more of its internal data ( la LLVM) instead of post-processing the output through an external script.

  3. #3
    Join Date
    Dec 2011
    Posts
    2,048

    Default About time

    About time!

    Good with some healthy competition!

  4. #4
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    It's funny how people who requested this in the past, or even provided patches, were ridiculed and laughed at.

    What changed?

  5. #5
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,891

    Default

    Quote Originally Posted by RealNC View Post
    It's funny how people who requested this in the past, or even provided patches, were ridiculed and laughed at.

    What changed?
    Not sure if you were being sarcastic or not RealNC, but i'll assume you werent and actually answer the question: LLVM.

    People can hate on the license all they want (personally it doesnt bug me too much but thats not the point) LLVM is producing similar-quality binaries, with better diagnositcs, with better integration to IDE, with faster compiles at less memory, AND a cleaner codebase. GCC could laugh at Clang for a little while, but Clang caught up while GCC stayed lazy. Now (4.7 and 4.8) they realized they really do need to get their shit together. If LLVM has a feature, then GCC wants the same feature. If GCC has a feature, LLVM wants it.

    Quite frankly...I think LLVM is gonna win out, and the GCC developers have already said why:

    LLVM has a better architecture and a cleaner code base. GCC wants that architecture now, but they cant GET that architecture because it would mean shelving GCC development for like a year while a small team refactors the entire codebase, and thats not feasible. So any changes to GCC are going to have to be done by either 1) a lone developer or two who integrates the changes back in via a massive patch or 2) Much smaller bit by bit conversion from one architecture to another that could be more error / bug prone way, but its the easier to get done with the whole community involved

  6. #6
    Join Date
    Jul 2010
    Posts
    98

    Default

    Quote Originally Posted by Ericg View Post
    Quite frankly...I think LLVM is gonna win out
    When it does, I'll have a beard.

  7. #7
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by RealNC View Post
    It's funny how people who requested this in the past, or even provided patches, were ridiculed and laughed at.

    What changed?
    When C11 introduced variable length arrays as mandatory, the pretence of keeping backward compatibility has dissipated to the point where the decision to self compile GCC using the C++ compiler was barely debated. A few highlights hardly seem important at this point...
    I suspect after C++14 file-system libraries, all hell will break loose and some radical changes will start happening all over the board...
    Last edited by c117152; 05-05-2013 at 12:11 AM. Reason: typo

  8. #8
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,891

    Default

    Quote Originally Posted by c117152 View Post
    When C11 introduced variable length arrays as mandatory, the pretence of keeping backward compatibility has dissipated to the point where the decision to self compile GCC using the C++ compiler was barely debated. A few highlights hardly seem important at this point...
    I suspect after C++14 file-system libraries, all hell will break loose and some radical changes will start happening all over the board...

    Can you point out where VLA's were made mandatory? LLVM has been submitting patches to the kernel to remove VLA's and if you compile with GCC with "-pedantic" aka: no non standard extensions, it refuses to compile a VLA

  9. #9
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    Quote Originally Posted by Ericg View Post
    Can you point out where VLA's were made mandatory? LLVM has been submitting patches to the kernel to remove VLA's and if you compile with GCC with "-pedantic" aka: no non standard extensions, it refuses to compile a VLA
    Actually it's the other way around. It's mandatory in C99, but it was made optional in C11 and a new macro was introduced (__STDC_NO_VLA__) in order to test for VLA support.

    If you compile with "-std=c99 -pedantic" or "-std=c11 -pedantic" (or the associated GNU modes "-std=gnu99" and "-std=gnu11") then you'll get no errors or warnings regarding VLAs. If you only compile with "-pedantic" then C89 mode is used, and therefore you'll get errors of course. What did you expect? :-/
    Last edited by RealNC; 05-05-2013 at 01:24 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •