LLVM 3.5 Brings C++1y Improvements, Unified 64-bit ARM Backend
An anonymous reader writes: LLVM 3.5 along with Clang 3.5 are now available for download. LLVM 3.5 offers many compiler advancements including a unified 64-bit ARM back-end from the merging of the Apple and community AArch64 back-ends, C++1y/C++1z language additions, self-hosting support of Clang on SPARC64, and various other compiler improvements.
It's one of those summaries.
You know "update on [OSS product]"
Why would we, the general populace of readers, want a very short summary of what this OSS product does, when we can have unclear references to the changelog?
Why would we want a link to the homepage with more information, when we can have 2 links that also are essentially changelogs, and one direct download?
If it's not the Linux Kernel, Firefox, or Chrome, please stop assuming everyone knows what it is.
The article pointed to the very very very very very incomplete release notes for stuff after 3.5.
You wanted to link to the 3.5 release notes.
I've been using LLVM and Clang a lot lately. They're an exceptionally good compiler system. The more I use it, the more I ask myself, Is there even any point continuing the development of GCC?
All software projects come to an end eventually. Something better comes along, and those who can't compete are better off giving up. I think that GCC has entered that phase, now that we have LLVM and Clang available to us.
LLVM and Clang have a better code base, a freer license, better runtime performance, better corporate support (probably because of the freer license), are proven to work well on major platforms like OS X and FreeBSD 10, and are starting to offer superb code optimization.
The only things GCC has in its favor are that it's entrenched, and that it supports some rarely-used languages and platforms that LLVM and Clang don't support. Neither of those is particularly impressive these days. People using Ada and Fortran use the better commercial compilers out there, not GCC. People using GCC on 1990s-era embedded systems are pretty much using a limited subset of C.
I don't even think that LLVM and Clang need the "competition" that GCC barely brings. The backers and developers of LLVM and Clang are motivated on their own to continually improve their product.
So I think GCC has started to outlive its usefulness. It may have been a trailblazer back in its heyday, but it's old hat now. There's really no need to continue developing it. LLVM and Clang are the future. GCC is a relic from the 1980s and 1990s.
Apple didn't contribute any work to LLVM/clang because LLVM/clang are licensed with U of I's BSD-ish and, as we all know, corporate capitalist pig-dogs will not contribute if they're not forced to by license requirements.
Can't believe anything you read on Slashdot these days.
Maw! Fire up the karma burner!
Oh dear. I guess your browser doesn't render the humor or sarcasm tags properly. The parent comment was intended to be snarky humor poking fun at those of us who think the gpl is a good idea. Whether or not it was actually funny is debatable of course.
rarely-used languages and platforms
Rarely-used platforms? Tell that to all the people developing for various embedded platforms like AVR which LLVM doesn't support. Those aren't rarely used.
Better corporate support? I might have missed it, but e.g. Intel, Google, ARM, AMD, etc. are still also making significant contributions to GCC.
Better runtime performance? Have you even read the Phoronix article?
People using Ada and Fortran using the better compilers out there... Eh... GNU Ada is *the* Ada compiler standard, and GNU Fortran is widely used even in high-performance computing because the commercial compilers aren't really better at all (and generally more buggy).
Go do your home work.
The FSF/GNU folks overreached with GPL v3. They overestimated their importance, pushed a little too hard, and get spanked by Darwin. Both the scientist and the kernel.
Gcc being displaced was bound to happen. When politics guide engineering the long term is doubtful.
Unfortunately this is a pretty spot on assessment of the situation in my mind.
Ok, It was annoying that companies were starting to find ways to use OS technology as center pieces in their products and not opening all of their source code to let people tinker with it. The problem their though is that in some cases if they did that then they would reveal too much about things like the underlying hardware that might be under NDA's forced upon them by other companies
Given enough time this sort of problem might have solved itself as companies slowly moved away from doing business in this way and embracing ideas that ultimately gave them long term benefit (ie: free code), but the GPL3 seemed a crude attempt to force too much change too quickly on business executives who have too much to lose, so are by that point in their careers too conservative.
I dont read
GCC's support for Fortran and Ada make it valuable, the point is the need for an open source compiler so when your requirement is open source a commercial compiler wont do. Many assiduously avoid closed source software and want to be able to have the facility for ada and fortran. Many "infrequently used" platforms are more important than you think, such as the system Z platform from IBM.
What's the LLVM / clang fuss about anyway? I keep hearing about LLVM for years already, it's presented by its' supporters (of which many have never actually even tried it out, I bet!) as "The Solution To All (alleged) GCC Problems", but it somehow fails to replace the GCC as an omnipresent compilation system.
Until there is not a single Linux distribuition out there compiled with LLVM / clang, and there still is none, it will just not cut it.
Besides, as the Phoronix article shows, it's also not on-par performance-wise.
I'd love to move to a compiler with better / more understandable errors and warnings, especially for C++, and which compiles faster - but until the code does not execute at the same speed (and it seems it mostly lags behind GCC), and until it is not integrated into the system adequately (read: LLVM-based distribution), I do not see the point in switching.
I don't follow the compilers very closely, so my recollection may be fuzzy, but I think this is what the grandparent was getting at:
In the past some people have proposed giving GCC a clear, serializable intermediate code so that one could use GCC front ends and back ends independently of the rest of GCC. The leadership viewed this as an end run around the GPL, because whatever produced or consumed this intermediate code would not need to link to the invoked portions of GCC. Tight coupling between the front ends and back ends was therefore treated as something to be encouraged for licensing reasons.
LLVM's design by contrast centers around its bytecode. Since it has a BSD-like license the question of whether you link to the compiler's code or fork/exec it is unimportant.
Since the emergence of LLVM, it's my understanding that the GCC leadership have softened their views -- the alternative to invoking GCC in a separate process is now to use LLVM, rather than to link to GCC and release one's source code; thus purely technical concerns can determine the design of GCC also.