Hi folks,

As most of you are on the GNU side of the fence, I believe this is the right crowd to first ask this question, before attempting a wider audience.

For a while, Clang/LLVM wasn't in any position to add unheard-of features, and most of what we needed would be covered by something GCC already did. But in the last year or so, there were a number of "features" we'd like to add that aren't present in GCC (like pragmas, attributes, asm directives) which is neither part of the language specifications, nor something that another standard (like OpenMP or ABIs) already support.

As a concrete example, we're trying to come up with some vectorisation annotation and there is a heated discussion on whether it should be C++11 attributes, pragmas, or changing the __attribute__ semantics to allow it to be used in lexical blocks, not just declarations. Any of that, but most strikingly the latter, would add Clang-specific behaviour which GCC probably won't implement, and we all know how that feels.

In this discussion, and others regarding ARM-specific behaviour (notably about assembly directives), I have used the same argument twice already, so it's time to ask the GCC crowd once and for all:

For non-standard, domain or platform specific changes, do we want to have a joint task force, GCC+LLVM, to homogenize the efforts in extending the languages we support in the same say, so that we can call it the "OSS Compiler Extensions" (or whatever) instead of two separate GCC-extensions and Clang-extensions?

Historically, GCC has *a lot* more extensions, so this new standard would probably be 99% GCC, but the goals of such a task force for the future would be to:

1. Make sure all OSS compilers implement the same extensions, when they so chose. So, extensions to the language should go in a shared forum, and not to Clang/GCC lists.

2. Document each extension and record all discussions (threads, bugs, etc), so that new compilers can have an easier time implementing them.

3. Reason about the existing hazardous or redundant extensions, and mark them for deprecation.

This is also pertinent to the Linux kernel, which is driving its own task force to compiler the kernel with Clang, so that it can rid itself from outdated GNU extensions that lingered for far too long in their code.

I appreciate the size of this proposal, the political issues and the endless discussions, but this is the same on every standard committee, and I'd rather have something than nothing at all.

Perhaps, as it happened before, some of these changes could be more easily persuaded to move back to the language standards and platforms ABIs, than if it's just implemented, undocumented, by one compiler.

So, ignoring just for a moment the political side of it, would that make technical sense for the GCC community as well?

cheers, --renato