Folks, I'm about to do something I've been advised against, but since I normally don't have good judgement, I'll risk it, because I think it's worth it. I know some people here share my views and this is the reason I'm writing this.
The problem For a long time already I've been hearing on the LLVM list people saying: "oh, ld should not accept this deprecated instruction, but we can't change that", "that would be a good idea, but we need to talk to the GCC guys first", and to be honest, nobody ever does. Worst still, with Clang and LLVM getting more traction recently, and with a lot of very interesting academic work being done, a lot of new things are getting into LLVM first (like the sanitizers, or some specialized pragmas) and we're dangerously close to start having clang-extensions, which in my humble opinion, would be a nightmare. We, on the other side of the fence, know very well how hard it is to keep with legacy undocumented gcc-extensions, and the ARM side is particularly filled with magical things, so I know very well how you guys would feel if you, one day, had to start implementing clang stuff without even participating in the original design just because someone relies on it. So, as far as I can see (please, correct me if I'm wrong), there are two critical problems that we're facing right now: 1. There IS an unnecessary fence between GCC and LLVM. License arguments are one reason why we can't share code as easily as we would like, but there is no argument against sharing ideas, cross-reporting bugs, helping each other implement a better compiler/linker/assembler/libraries just because of an artificial wall. We need to break this wall. I rarely see GCC folks reporting bugs on our side, or people saying "we should check with the GCC folks" actually doing it. We're not contagious folks, you know. Talking to GCC engineers won't make me a lesser LLVM engineer, and vice-versa. I happen to have a very deep respect for GCC *and* for my preferred personal license (GPLv3), but I also happen to work with LLVM, and I like it a lot. There is no contradiction on those statements, and I wish more people could share my opinion. 2. There are decisions that NEED to be shared. In the past, GCC implemented a lot of extensions because the standards weren't good enough. This has changed, but the fact that there will always be things that don't belong on any other standard, and are very specific to the toolchain inner workings, hasn't. It would be beneficial to both toolchains to have a shared forum where we could not only discuss how to solve problems better, but also keep track of the results, so we can use it as guidelines when implementing those features. Further still, other compilers would certainly benefit from such guidelines, if they want to interact with our toolchains. So, this wouldn't be just for our sake, but also for future technologies. We had a hard time figuring out why GCC would do this or that, and in the end, there was always a reason (mostly good, sometimes, not so much), but we wasted a lot of time following problems lost in translation. The Open Source Compiler Initiative My view is that we're unnecessarily duplicating a lot of the work to create a powerful toolchain. The license problems won't go away, so I don't think LLVM will ever disappear. But we're engineers, not lawyers, so we should solve the bigger technical problem in a way that we know how: by making things work. For the last year or two, Clang and GCC are approaching an asymptote as to what people believe a toolchain should be, but we won't converge to the same solution unless we talk. If we keep our ideas enclosed inside our own communities (who has the time to follow both gcc and llvm lists?), we'll forever fly around the expected target and never reach it. To solve the technical problem of duplicated work we just need to start talking to each other. This mailing list (or LLVM's) is not a good place, since the traffic is huge and not every one is interested, so I think we should have something else (another list? a web page? a bugzilla?) where we'd record all common problems and proposals for new features (not present in any standards), so that at least we know what the problems are. Getting to fix a problem or accepting a proposal would go a long way of having them as kosher on both compilers, and that could be considered as the standard compiler implementation, so other compilers, even the closed source ones, should follow suit. I'll be at the GNU Cauldron this year, feel free to come and discuss this and other ideas. I hope to participate more in the GCC side of things, and I wish some of you guys would do the same on our side. And hopefully, in a few years, we'll all be on the same side. I'll stop here, TL;DR; wise. Please, reply copying me, as I'm not (yet) subscribing to this list. Best Regards, --renato