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.

And the fun part is, that those "extensions" are enabled by default instead of a proper ANSI behavior.
Well, in any case I'm happy with LLVM and Clang, I use both and never had problems with assembly code, debugging and such (in fact, when I had a FreeBSD system around, I compiled the entire base system plus some software with Clang without issues)

ATM I prefer it over GCC, but if the chit-chat at the GCC mailing lists is somewhat true (plus, some advantages of LLVM/Clang), I'll use that version of GCC.

As for Micheal's comparisons against LLVM, first off the projects he names are using LLVM as a JIT compiler, GCC is a static compiler (barring GCJ I suppose) so comparing them in this area is pointless and currently LLVM's real success is as a JIT framework.

GCJ is staticly compiled. It also gives performance in many cases (at least with flags of removing bounds checking) in GCC range.
When dynamic runtime code is needed, GCJ goes in interpreted mode (which maybe here is where GCJ have bad rep).

That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.

In some ways it matters. Because if you want to write a C library that works on Windows you have to write __stdcall. These extensions are a part of working with real software. The good part is that CLang offers extensions by itself, in part for compatibility:

This document describes the language extensions provided by Clang. In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. Please see the GCC manual for more information on these extensions.

That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.

Unless you expect every compiler to compensate for the short-coming and quirks of other compilers, then it does matter. You cannot write code specific to compiler X, then complain that compiler Y won't compile your code and treat that as a short-coming of compiler Y.

read - STANDARDS, PORTABILITY

I think if LLVM/Clang was never created, then the GCC devs wouldn't be contemplating such improvements so soon (maybe in the next 7-10 years).

It does, if we want portable programming, it does.
Those extensions should be disabled when a project is setup, just like a programmer abstracts platform, this also makes up for portability...

Regards.

Whoosh! What's that? It's my point flying by over your heads?

You are attempting to assign blame, when that doesn't matter. All that matters to the end user is whether or not it works.

If Joe Blow can't install Magic Eight Ball software package in the latest Fedora release, it doesn't matter why. All Joe knows is that he used to be able to and now can't. Therefore the latest Fedora sucks.

Unless you expect every compiler to compensate for the short-coming and quirks of other compilers, then it does matter. You cannot write code specific to compiler X, then complain that compiler Y won't compile your code and treat that as a short-coming of compiler Y.

read - STANDARDS, PORTABILITY

You realise that these are 'extensions', as such they are not part of any standard and developers know this when they use them. Like Smitty said, all compiler have extensions, not only that but they also have exclusive extensions. The reason there are extensions is that there's a need/request for their functionality from programmers, this obviously also results in them being used in certain projects. Extensions which prove extremely useable will almost certainly be supported across compilers, and some of them even end up as parts of the standards. In short, writing standard compliant portable code is up to the programmer, not the compiler he/she uses.

Why so much focus on LLVM?

Even on a story which could (and should) have been focused on some free software project, Michael chooses to focus on his favored LLVM. I understand a person having favorite projects, but there needs to be much less reporter's bias here. Something that is almost never mentioned when it comes to stories regarding these and other free software projects are the licensing differences (if any), and the corresponding considerations.