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.

The issue is that a significant amount of open source software that uses GCC extensions to C/C++. If it were following the standard, there would not be a problem.

We could elect to look at this as a bug and simply fix it. Nothing the Open Source community hasn't done for years. Of there is value to any of the extensions I am sure patches will be accepted by LLVM to add them as well.

Besides the FreeBSD Ports team are working hard to patch such situations already so I doubt it will remain a problem for long.

Comment

Secondly, looking at how the FSF has run GCC e.g. you will see that they directly prohibited things like plugins for reason not of technology but to protect their ideological bend.

No I don't buy that at all, just like the reason GPL is the most widely used open source licence because programmers see it as a _practical_ way to get a 'quid pro quo' mechanism for their code, the same thing underlines the reluctance of plugins for the GCC project. It was so that GCC would not end up being a frontend/backend for closed source proprietary solutions and instead having all improvements made available to all. While you may see this as something ideological, I see it as practical. I also think it's alot easier getting corporations to contribute in a 'quid pro quo' environment than getting them to contribute when there's no need, and worse your competition may use your contributed enhancements together with their own (kept) enhancements to compete against you. This especially holds true with plugins where it's easy to maintain your proprietary code against an external project since the only changes you need to worry about are those of the plugin interface. But that's just my opinion, and I won't try to hold it as fact.

GCC is holding us back, the few areas where it currently leads such as proactive security I expect Clang will catch up shortly - as the tests show performance of the resulting code isn't holding for long.

Ahh, trying to portray GCC as a project that is standing still. But please explain how it is 'holding us back'? LLVM is there if you want to use it, and although it seems very popular again to use as backend for proprietary solutions there seems to be a shortage of corporate contribution aside from Apple. Meanwhile GCC has strong corporate support and even Intel hiring CodeSourcery to enhance optimizations for the Core Ix line.

I really see no facts supporting your claims but rather a whole lot of wishful thinking. And finally the one thing I think WILL be holding us back in this field is the lack of competition, thankfully now we have competition and I really don't want to lose it, unlike you.

Comment

Secondly, looking at how the FSF has run GCC e.g. you will see that they directly prohibited things like plugins for reason not of technology but to protect their ideological bend. Thus disallowing, in practice, the use of GCC for things such as static analysis which LLVM offers us today. Static code analysis is just one of many technologies we could and should deploy to ensure secure and performant code. The FSF playing politics with the compiler and their licensing has actively prevented that, in effect putting Open Source software in a worse place than it had to be (so much so that Coverity has made a small fortune running such tests on select codebases for us - using of course proprietary software which I hardly would call a win for ideology overall).

Thirdly, I prefer a BSD/X11 style license (specifically I am personally rather fond of the MS-PL license but that is besides the point).

So yeah, it's mostly about politics.

Making GCC effectively redundant code, and who wants to maintain two separate code paths which both have to be supported.

This is your other point, and I agree that there is something to be said about focusing developer resources on 1 compiler rather than 2. Clearly LLVM is using a much cleaner design and codebase, and it is much better suited to being used as a service inside other software, while GCC was designed to just compile applications more traditionally. Don't forget, though, that there are still lots of languages and architectures that GCC supports and LLVM doesn't, so it's not like LLVM is the only one that has any advantages over the other.

Anyway, I think there is actually a benefit to keeping some competition in the compiler arena, rather than just having everyone use the same thing. At the very least it should help keep software a little more friendly to being ported to other compilers.

FreeBSD have realized it's potential and have started this move

Let's not pretend that decision had anything to do with potential. FreeBSD doesn't like the GPL license and that's the reason they are switching.

The GCC situation is a bit more complicated than that. Importing new versions of GCC is a major PITA due to changes needed in FreeBSD not being accepted into the main GCC tree. We've been saying "gee, it would be great if we could get rid of GCC" since long before GPLv3 came out.

GPLv3 caused Apple to support LLVM development, which caused LLVM to be production-ready; and that combined with the general crappiness of gcc is causing FreeBSD to switch to LLVM. The licensing issue is a slight irritant, and without it we might have ended at 4.3 or 4.4 instead of 4.2.1; but it's certainly not the biggest issue.

Comment

What is this supposed to prove? Some BSD fan on the internet saying that the licence wasn't the biggest issue? And stating reasons as 'gcc's general crapiness'. I mean seriously, why are you linking to this licence fanboy drivel? Let's keep the compiler discussions on a technical level PLEASE!