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.

GCC hasn't run into the iceberg yet, but it's an old design (capable of doing a lot that LLVM can't yet). LLVM is the new shiny boat with some new modern features that GCC will probably never catch up with, but it's also a very different boat that can't do many of the things GCC can either.

GCC hasn't run into the iceberg yet, but it's an old design (capable of doing a lot that LLVM can't yet). LLVM is the new shiny boat with some new modern features that GCC will probably never catch up with, but it's also a very different boat that can't do many of the things GCC can either.

Why are you guys comparing LLVM to GCC? One is a virtual machine, the other one is compiler.

In terms of compilers, Clang is more like an artist's rendering at a yacht show. Most of it is not there, but the marketing is telling you that it will cure AIDS

Seriously, it's nice to see a good C/C++ compiler joining GCC, but Clang is not GCC's match in many many ways yet, despite nice features.

LLVM (formerly Low Level Virtual Machine) is a compiler infrastructure written in C++; it is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages. Originally implemented for C and C++, the language-agnostic design (and the success) of LLVM has since spawned a wide variety of front ends: languages with compilers which use LLVM include Objective-C, Fortran, Ada, Haskell, Java bytecode, Python, Ruby, ActionScript, GLSL, D, and Rust.[citation needed]

[...]

The name LLVM was originally an initialism for Low Level Virtual Machine, but the initialism caused widespread confusion because the scope of the project is not limited to the creation of virtual machines. As the scope of LLVM grew, it became an umbrella project that included a variety of other compiler and low-level tool technologies as well , making the name even less apt. As such, the project abandoned the initialism.[4] Now, LLVM is a brand that applies to the LLVM umbrella project, the LLVM intermediate representation, the LLVM debugger, the LLVM C++ standard library, etc.

Look up the history of GCC, the Free Software Foundation and RMS specifically and explicitly wanted GCC to be as monolithic and singular as possible so that closed source programs couldn't rip out individually pieces and incorporate them. I'm pro-FOSS and pro-OSS but the FSF's and RMS's shortsighted zeal is now catching up to them and have shoved them to this point: adapt or die.

Oh please, nowadays open source is established and the benefits of cooperative development is proven. Back then it was either scoffed at or ruefully being taken advantage of. The risk back then of a project like GCC ending up being nothing other than an open frontend/backend for proprietary frontends/backends was HUGE, you don't have look further than what Steve Jobs tried when at NeXT to understand that. And being a breeding ground for proprietary extensions was obviously NOT the intention of GCC, which (like other FSF projects) existed to foster Free Open Source, and a compiler toolchain was absolutely instrumental in that quest.

We can't overestimate the role GCC has played in getting open source to where it is at today, in no small part by being the de facto open source free compiler toolchain on which Linux, BSD's, OSX, and tons of other systems have been relying for their existance.

Now, THANKS to the acceptance of open source as pioneered by projects like GCC, the threat of proprietary interests have diminished, but that doesn't mean it's no longer there.

Apple funding LLVM and creating Clang came partly as a response to them not accepting GPLv3, but also because they wanted to be able to incorporate the compiler toolchain into their proprietary solutions, like XCode.

And here we see the risks, LLVM/Clang is due to it's licencing proprietary friendly. The reason GCC was hard work to develop against it from the 'outside' was to encourage development 'in-tree' so that the main project would benefit from all potential enhancements.

Modularity (like that of plugins) opens up alot of flexibility, but it also opens up easy ways to maintain proprietary functionality out-of tree which would otherwise be part of the main project and in everyone's hands.

Hopefully this won't happen, neither to Clang/LLVM nor GCC. I'd like to hope that companies of today see the benefits of sharing their work in areas like these through open source rather than 'keeping their secret sauce' either as a competitive advantage or for sale as proprietary 'addons'.

In other words I hope the incredible success of open source as exemplified by GCC will have made clear that the benefits of cooperative development dwarfs the potential gains that can be had by keeping improvements to 'yourself' and only part with them when there is a direct reward (like monetary).

Hopefully this won't happen, neither to Clang/LLVM nor GCC. I'd like to hope that companies of today see the benefits of sharing their work in areas like these through open source rather than 'keeping their secret sauce' either as a competitive advantage or for sale as proprietary 'addons'.

I think LLVM/Clang will be okay. , Apple incorporates many of its advancements back to FreeBSD, as does Netflix. Mostly because maintaining patches out-of-tree that have to be re-applied and tweaked after every rebase is hardwork that can be severely fscked over by upstream. Better to have your changes in upstream if for no better reason than to remove the maintenance burden from yourself.

* GPL licensed GCC has been made into a joke compared to the modern Clang/LLVM toolchain.

It is hilarious to see the incompetent GCC clowns shitting themselves as Clang/LLVM has exploded in use and development. Funny how now that developers and companies are free of the garbage GPL that there has been an explosion in code sharing and massive leaps forward in compiler development with Clang/LLVM.

But you would also benefit from reading carefully, because I've never called LLVM unimportant. So instead of throwing around baseless opinions about what you think I think, you should actually read what I wrote, it's only reasonable.

LLVM is one of the most important free software projects around and certainly the one with the biggest potential.

What advancements have apple incorporated back to FreeBSD? They open sourced Grand Dispatch which the FreeBSD devs ported, same goes for Clang. Meanwhile Apple released Darwin under a copyleft-style licence (GPL incompatible of course) which therefore is of no real use for the BSD's. Are there any other?

What about that dirndl?

Just curious - what happened to that dirndl complier Michael got all excited about a year or two ago? The EKOPATH 4 Compiler Suite that was open-sourced & "...can sharply outperform GCC in many computationally-intense workloads."
Wasn't that supposed to be "very big news for open source"? I'm just joe user & follow phoronix casually, but it seems a little odd this hasn't appeared since the 'big announcement'.
What's keeping you geeks from using that to build your programs? Why do you figure ubuntu's repos aren't made with it? (I'm assuming they aren't)

What advancements have apple incorporated back to FreeBSD? They open sourced Grand Dispatch which the FreeBSD devs ported, same goes for Clang. Meanwhile Apple released Darwin under a copyleft-style licence (GPL incompatible of course) which therefore is of no real use for the BSD's. Are there any other?

As far as I know, Apple open sources stuff on their website and the FreeBSD developers take what they want. xlocale is a good example of this.

Anyway, discussion of the GPL's compatibility with licenses Apple uses really has no place in a discussion of Apple code in FreeBSD. FreeBSD's base system has software under a variety of licenses, including the GPL.