If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

GCC 4.9 Diagnostics Will Begin Playing With Colors

05-02-2013, 10:20 AM

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

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

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

Comment

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

Comment

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

Comment

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? :-/