Announcement

Collapse
No announcement yet.

GCC 4.9 Diagnostics Will Begin Playing With Colors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Origin of colour ?

    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.

    Comment


    • #3
      About time

      About time!

      Good with some healthy competition!

      Comment


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

        What changed?

        Comment


        • #5
          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
          All opinions are my own not those of my employer if you know who they are.

          Comment


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

            Comment


            • #7
              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 May 2013, 12:11 AM. Reason: typo

              Comment


              • #8
                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
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #9
                  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 May 2013, 01:24 PM.

                  Comment

                  Working...
                  X