LLVM & GCC Compiler Developers To Begin Collaborating

An anonymous reader writes "While RMS is opposed to LLVM over its BSD-like license rather than the GPL, LLVM/Clang and GCC developers have agreed to try to start cooperating in an "open compiler initiative" to jointly tackle common issues that plague both compilers and issues that can be better served by working together rather than creating fragmentation between the two popular open-source compilers."

Comments

Open borders... one way?

[paxcoder]

I'm not sure how GCC could benefit from this.
While theoretically GPL could subsume BSD code produced from the collaboration, I reckon it's more likely that brains are going to migrate rather than code. And I don't see those working on LLVM (for commercial interest) migrating to GCC.
If I were RMS I'd be worried.

Re:Open borders... one way?

[kthreadd]

Well, just getting both camps into the same room from time to time would be an improvement.

Re:Open borders... one way?

[thoth]

I was a compiler grad student, and my university had its own intermediate representation it did work with. Back then (mid 90's) there was also SUIF (stanford university intermediate form), something I forget from University of Illinois... there were probably others too. But some big-name CS departments focused on other stuff, databases, operating systems, AI, and weren't necessarily up there in compilers or revealing the details of their intermediate form (not that it's was a secret, merely from academia the algorithm is more important than the intermediate form used).

Now, my old school adopted LLVM. I recently checked as I'm working with LLVM/Clang and found that quite interesting. I can't even pull up Stanford's SUIF compiler group research page (suif.stanford.edu, maybe I'm just unlucky or it's gone/moved/temporarily down). And LLVM/Clang is from University of Illinois... so yeah, I'm sure they are using it too.

The benefit to GCC from this is to not become obsolete in 5-10 years, from a steady influx of improved algorithms and tuning from a body of people that can easily contribute. Just from the fact LLVM/Clang is easier to work with, universities using it for their classes/research means that there is a steady crop of undergrads/grads familiar with LLVM/Clang and its set of libraries. They can contribute, and the research community doesn't have to roll its own intermediate form for research algorithm implementation and then throw that out when it comes to implementing the same algorithms in an actual intermediate language that is used in a real compiler. When you're a student, the last thing you want to do when you've got a project due in the semester, or you are trying to write your thesis/dissertation and graduate, is screw with compiler internals that are purposely difficult to work with (GCC).

Yes, GCC has a core group that has done an excellent job. But they are facing commercial interests improving the LLVM/Clang (i.e. Apple and Obj-C) plus now the OpenCL and OpenMP work going on, and on top of that an ever growing population of former students with skills/knowledge and perhaps the desire to contribute.

f I were RMS I'd be worried.

Agreed. Those years he opposed modularizing GCC might have really hurt the project in a way that isn't done being felt yet.

Re:RMS needs to get over the GPL

[Anonymous Coward]

Do companies contribute back? Sure, some do, some of the things. But everything else is competition.

I would be very interested in seeing real statistics on this, because my experiences with companies using BSD style licensed code in their software suggests the exact opposite. There are a number of reasons to use open source software in your project, the chief among them being "not reinventing the wheel". The problem is, the moment you generate your own proprietary fork, you're back to reinventing the wheel. Chances are, you made the changes because the software in question didn't quite do what you wanted it to do, or to fix a bug. Great, so now you've got your own branch, and every time you update this software with the latest "official" version for whatever reason (including perhaps, not reinventing the wheel for some new feature) you have to apply your patches and changes, and hope that the patches you built against version X are still valid against version Y.

In my experience, the only time companies don't give back is when they've made such massive changes that they would be maintaining their own branch anyway. And with changes that large, it's extremely unlikely the main branch would ever integrate them all back in, which means the company is maintaining their own fork, regardless of whether or not they've released the code. Now, you can argue (as RMS does) that regardless, the important thing is whether the new code is open, not whether it's ever merged back, but there are considerations to be had as well. Forks split and consume development resources. Different projects all doing the same thing slightly differently create more work for people trying to target those projects, such that writing new useful software that takes advantage of other available resources either requires multiple code paths to handle each resource (think vendor specific CSS tags but worse) or can't be meaningfully built without someone writing additional code.