Slashdot Mirror
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.
Nerds are not interested in champagne & handbags. Get ye to idle!
It's true I tell you, feller at work's next door neighbour read it in the paper.
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!
Maybe if you had read the release notes you wouldn't have posted such a retarded comment. Oh, and large chunks of the llvm/clang team work at Apple.
"During the 3.5 release cycle, Apple released the source used to generate 64-bit ARM programs on iOS platforms. This took the form of a separate backend that had been developed in parallel to, and largely isolation from, the existing code.
We decided that maintaining the two backends indefinitely was not an option, since their features almost entirely overlapped. However, the implementation details in both were different enough that any merge had to firmly start with one backend as the core and cherry-pick the best features and optimisations from the other.
After discussion, we decided to start with the Apple backend (called ARM64 at the time) since it was older, more thoroughly tested in production use, and had fewer idiosyncracies in the implementation details.
Many people from across the community worked throughout April and May to ensure that this merge destination had all the features we wanted, from both sources. In many cases we could simply copy code across; others needed heavy modification for the new host; in the most worthwhile, we looked at both implementations and combined the best features of each in an entirely new way.
We had also decided that the name of the combined backend should be AArch64, following ARM’s official documentation. So, at the end of May the old AArch64 directory was removed, and ARM64 renamed into its place.
"
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.
Never underestimate the power of entrenchment and inertia. None of the embedded projects that I use (or heard of) are moving away from GCC.
GCC is pretty awesome, available for countless arches, everyone knows it, and it gets the job done. I just don't see it rolling over and dying any time soon.
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.
Go read gpl-violations.org's mailing list.
At least 3/4s of *EVERYBODY* are violating the GPL and not releasing source code. And we're not talking small companies either. Mediatek, Allwinner, TomTom, Renault (via TomTom derived systems), Zyxel, etc.
The real solution to this whole shitfest is either to start enforcing criminal copyright law vigorously against everyone, let the rich abuse the 'lower' classes, or simply abolish copyright law and let it turn into a free for all. If nobody is going to obey the rule of law (And give that both corporations and the government seem to be flagrantly violating it while demanding laws beneficial to them be enforced vigorously), then there's no point in rule of law existing, in which case we should go back to rule by force or rule by mob, which isn't far from the way things are being treated nowadays.
Actually I still use gcc for gfortran - I can't personally afford to use the commercial license, and I have code I want to maintain and develop in Fortran. But on Windows I develop C++ in either MSVC, due chiefly to the fact I like its debugger better than any other I've worked with, or in Clang, and on Linux I develop C++ in Clang. I'm glad gcc is there but my default these days is certainly Clang.
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.
"GNU Fortran is widely used even in high-performance computing because the commercial compilers aren't really better at all (and generally more buggy)."
While I've certainly encountered (and notified Intel of) bugs in ifort, and more than I'd expect in something that cost the university a pretty parcel of money, I wouldn't even begin to pretend that gfortran is as good for high-performance computing as ifort. Unless you're triggering an ifort bug, and I haven't hit a genuinely serious one since a weird memory cap back in 2005, or using ifort on some esoteric architecture, you are *never* getting better performance out of gfortran optimised code compared to ifort optimised code. They may be equivalent for a lot of operations, but for others ifort is simply a lot better, particularly when tuned to a particular Intel chipset. I use gfortran a lot and I don't have any serious complaints about its optimisation, but ifort's is better.
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.
ARM's new compiler for embedded IP cores is LLVM based, so many commercial projects will be using it, but not necessarily knowing about it (they typically buy the toolchain, sometimes set up as ready-to-go VM's, and just hit build in eclipse/other IDE).
The GCC team is merging with LLVM. Even they think GCC is hopeless in the long run.
The Mozilla Firefox web browser is the open-source successor to Netscape Navigator. (In fact, Netscape Navigator has been built with the same Gecko engine that powers Firefox since Netscape 6.) And the Firefox developers are doing interesting things with LLVM, such as static analysis and the ASan bounds checker.
If GCC's Fortran and Ada support are so valuable, then why do they see so little use? I worked in the aerospace industry for years, and more recently in physics research in academic settings. Ada was and is still used in industry, but commercial compilers were and are the norm. The same goes for Fortran in industry and academia. Anyone doing anything remotely serious, even if they're just grad students, will end up using a commercial compiler specifically targeting the platform they're working with. Even undergrads will typically avoid the GCC Fortran compiler if they can, because it's, well, not very good at all. Ada and Fortran are used, but GCC is very rarely used to compile software written in those languages.
And anyone using System z or similar systems is using one of the commercial compilers. You're not going to pay large sums of money on hardware and system software, only to squander it away by using a half-assed Ada or Fortran compiler like GCC. And if you're one of those hold-outs still using a Sun workstation from the 1990s, you might as well just get the shittiest consumer-grade PC you can find these days. It'll be far faster than that Sun workstation.
Better runtime performance? Have you even read the Phoronix article?
So there is just one, right? One lone article on Phoronix?
I'm just curious to know what metrics you used to determine that LLVM/Clang have "a better code base" .. ?
Well, the "advantage" of GCC is it's GPL. To a large number of FOSS people, the GPL is a far better license than BSD, so it doesn't matter if LLVM/CLang is better, superior or whatever, GCC is GPL and that is all that matters.
Also, there's a lot of GCC-isms out there in the code, many of which are not supported by LLVM/Clang or other compilers and they often do strange things so porting them to use another compiler is often difficult.
And GCC supports far more backends and languages, so it still has a place.
Of course, LLVM/Clang is progressing quickly because of extensive corporate support (being BSD licensed versus GPLv3), and projects like Free/Net/OpenBSD love the fact that the entire base OS can be BSD licensed now rather than having to rely on a non-BSD component.
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.
While both GCC and Clang are buggy, I have found that some of the bugs of clang were more problematic than gcc's.
That's a good reason for gcc to go on living.
I'm using GNAT Ada with GCC, as practically all other Ada users. GNAT is the only Ada version that implements the latest language features of Ada 2012.
Adacore alone is reason enough to continue developing GCC. The commercial version of GNAT uses GCC and is used in production systems like airplanes you fly with.
Instead of only talking out of my a$$, I just compiled a small QT project of mine (8333 LOC, spread over 60 files (including auto generated moc files), lines counted with "wc -l"), with gcc 4.8.2 and with clang 3.5 (these are per default available on Ubuntu 14.04), and it seems that the compilation times are nearly identical:
CLANG:
real 0m26.100s
user 0m24.815s
sys 0m1.208s
GCC:
real 0m27.936s
user 0m26.715s
sys 0m1.755s
All files (including compilers, libraries and includes) are on an SSD. Difference of 2 seconds or some 7%. Not exactly to be ignored, but not enough to make me smile either. At least I didn't have to change much to get it to compile, except replacing 1.0d with (double)1.0.
Actually, it seems that Phoronix tests are the best available around - at least a quick search didn't reveal any further recent tests. Besides, that's what TFA links to.
If you wish to imply that Phoronix tests are somehow skewed in favour of GCC, why don't you provide a link to tests claiming otherwise?
http://linux.slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
Slashdot has everything a nerd could want
Apart from two things: Editors and Journalism.
Here's how I measure it:
1. I pick a certain part of the compiler, or a certain piece of functionality. Let's say the handling of C++'s throw() specifier, as an example.
2. I find the LLVM/Clang code for handling that functionality. It's easy to find, and then it's easy to follow. The code is clear, concise, and well structured.
3. I try to find the GCC code for handling that functionality. It's hard to find, and even once it's found it's hard to follow. The code is unclear, and usually not very well structured.
4. Repeat the above steps for other compiler or language functionality, noticing that it's always much easier to find and follow LLVM/Clang's code than it is to follow GCC's.
I've been using C on nearly a daily basis in industry for over 25 years now. I've been using C++ almost daily for over 20 years. I've seen a lot of code in both languages, and I've written a lot of code in both languages. I can tell you for a fact that LLVM/Clang's code is very clean, especially for a project of its size and complexity. GCC's code, on the other hand, is not very maintainable at all. Hell, this is probably why we've seen LLVM/Clang advance so quickly and even pass GCC in most ways, while GCC is struggling to remain relevant.
Do you need a metric to determine that pizza tastes better than dog shit? Take a look at the GCC codebase and take a look at the llvm/clang codebase. I don't know how anyone could dispute it. (Even if you hate C++, GCC code emulated C++ and has finally started using C++ directly). GCC intentionally fucked up their code for political reasons (to keep people from bypassing the GPL spirit). llvm/clang also have the advantage of being a newer codebase. Some of GCC's code dates back to the 80s and they assume you may be using a 1986-era SunOS k&r compiler to bootstrap it. Remember how OpenSSL has pages of #ifdefs to support Windows 2.0 or big-endian x86 (no joke)? GCC is just as bad.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Try compiling Freeorion sometime.
Hint: if you build with debugging enabled, you need -Wa,--compress-debug-sections. One library alone generates 1.2GB of debug data. LLVM 3.5 now supports this option.
So, Linus found a bug and it was fixed. Whop dee doo.
It's getting common to develop C++ with Clang, then distribute with GCC.
Though it's not huge in Linux camps, BSD is using Clang.
LLVMLinux getting closer (similar performance, and very few patches needed, soon none):
http://www.phoronix.com/scan.php?page=news_item&px=MTcxNDA
and it compiles Debian's repos quite well too, with most problems being edge cases and standard differences.
Distributions need this groundwork first.
No, my point is that there are quite a lot of articles re: GCC vs. Clang on Phoronix, and that the comparisons are quite a bit more thorough and the results more varied than the parent hinted at with his/her implied claim that ‘the’ Phoronix article proves how GCC runtime performance is better. I read another article (at http://www.phoronix.com/scan.p...), and though it’s half a year old, it still shows that the compilers can be neck to neck in one area, and that they beat one another in various tests. So neither can claim absolute superiority.