Slashdot Mirror
FreeBSD 10 To Use Clang Compiler, Deprecate GCC
An anonymous reader writes "Shared in last quarter's FreeBSD status report are developer plans to have LLVM/Clang become the default compiler and to deprecate GCC. Clang can now build most packages and suit well for their BSD needs. They also plan to have a full BSD-licensed C++11 stack in FreeBSD 10."
Says the article, too: "Some vendors have also been playing around with the idea of using Clang to build the Linux kernel (it's possible to do with certain kernel configurations, patches, and other headaches)."
What's wrong with GCC?
and suit well for their BSD needs
In other words, it has the license they want. GCC was a thorn in the side of the collective BSD conscience, they didn't like it.
"First they came for the slanderers and i said nothing."
Having all this great open source compiler technology competing with each other is great, but one does wonder if the alienation caused by GPLv3 was worth it, as it is the primary reason both Apple and FreeBSD embraced Clang (in fact, Apple started the Clang project). As a result, GCC wasn't updated past GPLv2 on either platform. Apple couldn't integrate GCC with their IDE like they wanted, nor could FreeBSD's commercial clients work with it. Flexibility and pragmatism usually wins out over rigidness and ideology.
While the BSD licensing model allows various hijinks to go around without the requirement of disclosure.
Complaining about the GPL is like complaining that you can't play dirty pool with code licensing(see Tivoization). Then again, you probably would rather throw some ad hominem at me regarding a certain GPL advocate.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
I've heard positive and negative claims regarding this. Certainly, Apple thinks it's production-ready (I think it was Xcode 4.2 that they stopped shipping GCC). Do you have a link showing that generated code is significantly worse? Which versions were compared?
What's wrong with GCC?
Some people argue that LLVM/Clang offers better code generation, compile time warnings, and code analysis. Some compiler developers think the gcc code has become too bloated and complicated. Even gcc devs have described the gcc code as "cumbersome".
There are various efforts to get Linux building under LLVM/Clang. Especially for embedded environments.
While both compilers are very good, I find myself preferring Clang both on technical and licensing merits. Putting aside the license for a moment, Clang gives better warnings/errors. They are clearly defined and easier to read. In addition I've found some GCC warnings are not accurate. To date Clang hasn't given me any bad advice.
#include <stdio.h>
#if defined( __GNUC__)
static char* world_type = "free ";
#elsif defined(__clang__)
static char* world_type = "unencumbered ";
#else
static char* world_type = "";
#endif
int main( int argc, char** argv )
{
printf( "hello, %sworld.\n", world_type );
return 0;
}
Stallman and others deliberately fought having APIs, proper documentation and to allow plugins for all parts of the GCC toolchain, to keep control of the thing.
If you're on slashdot and you just discovered that Apple hates the GPL, youre wrong. Your first clue was when they banned GPL from the crap store.
However, FreeBSD will not actively block you from using a newer version of GCC.
Using newer version of GCC and binutils with the FreeBSD Ports Collection
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
The only valid way of integrating compiler with custom tools is calling the compiler from them
So what's the valid way of finding what functions exist and what variables belong to what functions? Such functionality is needed for "go to definition of selected symbol" and "search for uses of selected symbol" actions.
Stallman and others deliberately fought having APIs, proper documentation and to allow plugins for all parts of the GCC toolchain, to keep control of the thing.
Mostly result of dispute with DEC SRC when GCC and parent FSF failed to enforce GPL on Modula-3. Moving target known as GCC internals has been problem ever since, mostly to "legitimate" GNU compiler developers.
LLVM, on the other hand, made ingenious move with standard and open IR. Overall modular design is another boon.
GCC was in blind alleys before. No real reason for them not to survive this one. Another EGC can happen, to pull GCC in future.
http://opencm3.net, http://www.nongnu.org/gm2/
I've found that code that will compile properly under a variety of compilers tends to be of better quality.
One of my current projects started out on an old 2.x branch of GCC. When I finally got around to updating to a current GCC, I had to fix quite a few bugs before it would actually work - the different compiler was catching problems I hadn't noticed before.
Same when I tried compiling it under Visual Studio, or Clang - the more compilers I made it work under, the less bugs there were in the code.
Now, if a given program actually uses some special feature of GCC, that's fine - if only one compiler will do what you need, that's fine. Or if it's too much work to maintain a "port" - I stopped maintaining the VS project files a while ago, since I no longer used it. But if you have a chance to at least test it against a different compiler, go ahead and give it a shot.
But Clang also has many technical superiorities to GCC too. Wikipedia gives a quick outline of them.
http://en.wikipedia.org/wiki/Clang
And at the top right of that page is this picture. Which Pokemon is that?
... Which is hilarious because it is the BSD fundamentalists who are re-implementing huge projects just to avoid a license they don't like for no reason other than political correctness ...
Untrue. Gcc is handicapped by political decisions in it technical design. It intentionally does not allow "others" to plug into some "internals". "Internals" that would facilitate other tool builders, especially those creating a graphical integrated development environment.
LLVM/Clang doesn't come with such technical baggage. Its modular rather than monolithic. It is a newer code base that is far easier to work with, even gcc devs moan about the bloat/complexity of their code base. Nearly all long lived project reach a point where it is better to toss the legacy code out and start from scratch, gcc may have very well surpassed that point.
And on some platforms LLVM/Clang simply generates better code.
The quality of the generated code, however, is significantly worse, at least at this time.
That may not be accurate. My understanding is that on some platforms LLVM/Clang has the advantage.
http://www.networkworld.com/community/blog/apple-ditches-mysql-favor-postgresql
It is all about politics, performance be damned.
Their kernel performance sucks. How many people have you heard using MacOS for server tasks? Probably even Apple isn't using it by now if they can avoid it.
The only valid way of integrating compiler with custom tools is calling the compiler from them
So when will GCC provide a way to recompile one function within a translation unit without recompiling all other functions within the same translation unit? Does it already?
Both Apple and FreeBSD didn't want to adopt the GPLv3 versions of GCC, so they were stuck at GCC 4.2. Compared to that GCC version, the code generated by LLVM/Clang is not worse, in my experience.
The quality of the generated code, however, is significantly worse, at least at this time.
At work, I use Clang to compile my DSP code, and the result is faster than if I use GCC. I haven't rigorously analyzed the situation but the speedup is on the order of 5% to 10% for my code; not dramatic, but nothing to sneer at either, and all I had to do was edit my makefile to specify Clang.
So I find the blanket statement that Clang generates "significantly worse" code rather surprising. My own experience says otherwise.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
[oops... wrong web site]
Run time optimizations can be (are?) a very bad idea in a kernel, where very often the exact predictability of execution paths makes the difference between a working kernel and a misbehaving one.
Huh? No.
If a code optimization causes a problem with the kernel, there is either a bug in the high-level code, where the constraints of the language have been violated by introducing an invalid runtime assumption, or a bug in the optimization procedure.
If specific code output were required, it should have been entered explicitly in the lower level language.
From a licensing perspective the problem with recent GCC versions for Apple is the anti-DRM clauses in GPLv3. Note that Git is explicitly GPLv2 licensed.
Of course the technical problems with some parts of GCC's design are undoubtedly significant too, though these are nothing to do with the GPL (v2 or v3) specifically. From what I've read there were deliberate design decisions that make it inconvenient for GCC to be used this way (some say this was deliberate rather than those decisions being made because they had benefits elsewhere, though without evidence to offer I'll not parrot that accusation).
I believe it was really the Tivozation rule of GPLv3 that forced FreeBSD to abandon GCC in their base. FreeBSD wanted to ensure that a specific version of GCC would be in their highly integrated base operating system. The FreeBSD base has no real comparable analogue in the Linux world, but its a system that is tested and designed to work together from the pseudocode to the final compiled product. GPLv3, with its Tivozation clause, however, made this tying together essentially illegal.
Also the BSDs have long since desired to remove GCC from their base system simply because it has a different license than the rest of the base. They attempted using PCC, but the code it produced was not optimized to a level comparable with GCC. clang/LLVM however, is both BSD licensed and produces well optimized code. Its also newer and cleaner code; sometimes rebuilding everything from scratch helps (though usually not).
Of course, its a pity, because even if if you Tivoized GPLv2 code you still had to share your source so people could learn from it, or use and modify it on other (or jailbroken) hardware, whereas now people are moving to BSD-style licenses with no such benefits... but if the FSF want to let the perfect be the enemy of the good, declare jihad on Tivoization and have a tilt at the patent windmill, that is their right.
This is absolutely the case! When TiVo was complying w/ GPLv2, the FSF suddenly discovered a major objection to their practice - namely, that they were putting the code in read-only devices, and declared a jihad on the company. However, even GPLv3 doesn't explicitly say that GPL software cannot be put on a Read-only memory (which would again violate the GNU's Freedom #3) or copy-protect memory (which could prevent the device that contains the software from getting copied) or anything else about the devices that the software can reside on.
As you very well put it, it's one more of those cases of the perfect being the enemy of the good, and in the process, the FSF waging a war on its own licensees, namely TiVo. Given that track record, which company in its right mind, even if they endorsed the liberation of software, would want to get into bed w/ the FSF?
There are a number of things attractive with LLVM/Clang: the code base is cleaner, some people feel better about the license, and so on. The quality of the generated code, however, is significantly worse, at least at this time.
Most of the time, code quality doesn't matter. In the very few cases where code quality really mattered to me, gcc and llvm optimisers both went out of their way to make it hard to create optimal code.
GCC is doing just fine and there is plenty of cooperation between clang-developers and GCC-developers. As always, the war only exists in the minds of the fanboys on each side.
Btw, the latest improvement in GCC is to move new development to C++ which will allow for much cleaner and more maintainable code.
I am a bogeyman, you insensitive clod
Sent from my ASR33 using ASCII
You haven't used any of the modern architectures then. We routinely have to shut off optimizations in kernel level and reatltime work simply because they cause incorrect code to be produced relative to the architecture we're targeting. You could argue that it is a problem with the architectures, and you'd be correct. But we don't make those.
I am TheRaven on Soylent News
GCC doesn't need GPL, a freeware license would suffice.
Over the years I've read and analyzed the sources and consistently found the source to be as readable as the binary code, regardless of platform.
Compiler developer forums seem to confirm my findings with frequent comments and insults on GCC like:
Nonetheless, I praise the omnipotence of GCC, as long as I'm not the first guy on a new platform.
GNU (especially in the context of the GPL) is very much strongly in favor of copyright. Without copyright law, there's no way to legally enforce the GPL. Copyright licensing law is exactly how the GPL prevents people from taking a project, forking it, and making it proprietary.
Now, you can certainly claim that, as a libertarian, you're just fine with people having the ability to do that, but that's fighting the GPL (even if you personally would honor it, you're still fighting against what it stands for - the protection against misuse by the unscrupulous).
There's no place I could be, since I've found Serenity...
Somebody mod above post up, please. TheRaven64 knows compiler stuff.
It seems possible that the reason my code is faster is due to the autovectorization stuff. DSP code generally is a good candidate for vectorizing, and my code is straight C with no explicit use of SIMD features.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I'm a 10 year+ FreeBSD contributor. You're all missing the point. Linux and BSD target different markets and are optimized in all ways, organization, release process, license, code, to fit these different needs. One isn't better or worse. Obviously Linux is larger in all ways than BSD but larger doesn't mean better or we'd all just be using windows. This isn't a question of llvm being better than gcc, bsd being better than linux, or bsd license being better than gpl. They are just different and do different things. Use what's appropriate for your needs and leave it at that.
I can say as a long time contributor to opensource software I am disgusted at reading the comments of blowhard 'enthusiasts' who denigrate the hard work and contributions of hundreds of people when they get in these pissing matches. I am friend with Linux kernel contributors and I can guarantee we don't flame each other in this manner.
I know there are reports that C is even with Java again. But what you say made me wonder about this. Despite what Java advocates say, the idea of the app server and enterprise Java was not new to Java. There were and still are brokers around that do much of what a Java app server does, but using C/C++. Tuxedo is one. The thing I am thinking about however, is that Java started a heyday when groups like Apache came around and there was a huge resource of Java utilities and helpers and libraries that were free, and free of encumbering licenses like the GNU license. And Apache thrives despite not having the clause that says you have to give your code away if you use any part of theirs'.
I'm theorizing that Java took off because despite being further behind in enterprise architecture than C at the time (remember Tuxedo et al), it had a support community that didn't encumber the companies, so they backed this stream. C which also has a ton of libraries, but was hamstrung by GNU and thus falling behind in business use case libraries (and those being made being GNU laden and repulsive to most businesses). I see this as the reason for Java's rapid rise. I think it has faltered lately with the crap Oracle has and is trying to pull with Java which is although at the opposite end of the spectrum is just as hampering to other businesses as is the GNU license.
Anyway, maybe with a BSD (and Apache like... although yes, Apache is really BSD-like) licensed compiler, and maybe the founding of an Apache like foundation (how about C is for Comanche?), the C language can take off again.
P.S. as to your route around the license by using other types: of course you're right. It is like all software. If you bring in something that people are supposed to use at work say, but the software makes it harder to do than by hand, people will start doing things by hand again. Even if it is slightly easier but it makes it frustrating for whatever reason, they will find some other way to do the work. It takes people with real foresight to understand this though.
-- I ignore anonymous replies to my comments and postings.
LLVM internals are not better documented than GCC.
...is the one the GCC team is about to throw out: the fact that it's written in C rather than C++.
An FPGA will always be more wasteful of power than an equivalent hardwired solution.
Contribute to civilization: ari.aynrand.org/donate
At the moment I write this there are 297 comments mostly debating the merits of LLVM/Clang vs. GCC. There is not one mention of EGCS.
Fifteen years ago GCC was forked. A group of people we're frustrated with GCC and its leadership because they had contributions to make and talent to offer that was not welcome. They called their fork EGCS.
Why are we doing this? It's become increasingly clear in the course of hacking events that the FSF's needs for gcc2 are at odds with the objectives of many in the community who have done lots of hacking and improvment [sic] over the years.
The GCC you use today is EGCS. A few years later EGCS was adopted as GCC 2.95 after the merits of EGCS became undeniable.
Looks like we've come full circle. The cool kids are off in the weeds making cool stuff. Better stuff, and the `Powers That Be' are not interested. The `needs' of the FSF today are no longer in sync with the `needs' of the developers of today.
The bottom line is that GCC as it is with it's leadership, code base and license agenda doesn't cut it for those who have the talent, motivation and capital to create a tool chain that does cut it. You don't get to impede that, however righteous you think you are.
Freedom. Deal with it.
Lurking at the bottom of the gravity well, getting old
GPL is about the USERS freedom. The software is inanimate and doesn't give a crap. It's the users of the software that the GPL is intended to protect. I understand that many developers like to make a buck. I also understand that some developers want to use other peoples work for free but don't want their users to benefit in the same way. For them it's BSD.
What baffles me though is this use of a technically inferior compiler. I could see in a few years if LLVM can produce comparable code in more cases. But to provide users with a different free (as in beer) compiler just because of GPL vs BSD license really points to some kind of deep rooted bias. And yes, I believe LLVM is not up to par in terms of generated code, YMMV of course.
Nested functions as context manipulation is extremly useful in large code bases.
I think that static functions and a clever use of the file system are a better alternative.
Nested functions are nice in a small scale, but once the code grows the file becames a huge monster hard to parallelize development (and to maintain).
I remember my Pascal times - I endup giving up nested functions in favor of modules very fast.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
So is there any Objective Clang for Objective C?
Yes.
Do you even lift?
These aren't the 'roids you're looking for.
TiVo and that Xerox printer @ MIT are apples and pineapples. In the case of the latter, RMS and his group wanted to get the source code of the drivers so that they could compile it for the platform they were using. It didn't involve altering anything in the printer itself that could risk making it unworkable. TiVo was about locking that box itself - but if someone wanted to write a driver whereby a Linuxstation could get inputs from a TiVo box and display it, instead of connecting it to a TV, then the TiVo contents on that flash are very much open sourced.
TiVo completely went along w/ the GPLv2. I believe that they do provide the source code, or else, they'd have been accused of violating GPLv2 itself. But that's not the case - they were compliant w/ GPLv2, and the FSF accused them of using a loophole - namely, their putting the code on a flash memory device that they had protected, and which could only be altered by them. B'cos TiVo got around what FSF perceived was a loophole, the latter wrote GPLv3, specifically naming them as a criminal in one of their sections.
Theoretically, there was nothing preventing anybody from taking the contents of the TiVo flash - via the GPLv2 source code - and slapping it on a non-TiVo box, and releasing it on a pirate shop. But doing so would be as expensive as TiVo itself doing it. The Software Liberators are more upset about the fact that TiVo can update the firmware on their box, but no-one else can, b'cos TiVo's write-protection is NOT FOSS.
I do think that the Freetards prefer it if only software liberators use their software, but that's what brings them into conflict w/ Linus, who makes it a point nowadays not to refer to Linux as free software. Aside from that, the choice TiVo had woud have been to use one of the embedded OSs, like NetBSD, QNX, WindRiver or today, even Minix 3.2. That way, they get to do what they want w/o being in the cross-hairs of RMS's Software Liberation Army.
Yes AC Apple fanboy.
Just a note, right here you basically said you are retarded. In the literal sense; something is holding you back mentally, and that's a big warning sign that tells us all it is so.
Just because some people do not care about being ripped off by companies owned by billionaires doesn't mean all of us are like that.
That makes no sense. If I put something out into the world and state "anyone can use it" then why would I care if the people who made use of it are rich or poor?
That's what the BSD guys have done.
Even the GPL guys do not care if someone is rich or poor; what they do care about is if any changes are made they want to see them. A perfectly reasonable philosophy, one I understand and support, but again rich/poor never entered into the thing.
You seem to be mentally stuck in some really juvenile state where supposedly you want to give something away for free (in reality I very much doubt you've given away anything) but if anyone with money wants to use it, well then! You want some of that action.
In short your words and desires are abhorrent to anyone truly behind either a BSD or GPL world.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
C'mon Apple people, please back off the reality distortion. LLVM has a lot of interesting points to recommend it, but one those is very definitely not beating GCC in code optimization.
Not yet - but it's not far behind. The only tests where it varied much were tests where OpenMP was involved, which Clang does not support yet.
Also, back in the day when I used GCC I pretty much never turned on full GCC optimizations because I would run into odd issues at times if I tried. Sure in bench marks GCC is ahead, but how much really world code has GCC enabled with full optimization - especially a brand new GCC version like 4.7?
As you noted LLVM has a lot of other interesting points, and the fact that the optimization is already so close to the existing battle-tested solution is a good reason for more people to migrate to the more flexible architecture of Clang/LLVM ASAP.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you're against copyright, then you're against the GPL.
I'm a Libertarian. I'm not "against copyright". At least not reasonable copyright.
But you're also wrong in another regard. Even if you are wholly against copyright you can still be for the GPL, because it subverts the intent of copyright to accomplish something totally different. That's what I always admired about the GPL, how it used the dark side of copyright to accomplish something positive.
It's a fine bit of judo.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Libertarians love to pine for a sort of Mad Max style of anarchy believing themsleves to be on the top of the food chain.
Libertarians want nothing to do with anarchy.
We want to take over and then LEAVE YOU THE HELL ALONE. Which kind of vaporizes your whole power fantasy.
Libertarians only care about power insomuch as other people are limited in what power they can use against the individual. It does not mean a vacuum.
You would seem to prefer to be enslaved. Understandable since you are usually treated well, as long as you enjoy the castration which you seem to. Fine then; but the rest of on would rather keep our tackle box intact.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Talking about 'fundamentalism' and 'how bad the other people are' is childish (yes, I'm calling you childish, Bonch).
You seem to be the only childish one here. Everyone is debating without calling names.
You are twisting his words to claim his position is extremist - but then YOU go on to present a worldview far more extreme than anything he laid out:
1) BSD: if you want your software used by corporations, and you don't care if you get anything back as a result. You are interested in fame.
2) GPL: if you want to help people out, but don't want a corporation to make millions without giving back. Your code might not get used as much, but you're fine with that.
A real open source programmer would not care anything about the money involved, they shared code to be used.
More specifically a BSD programmer is not after fame; again they want to share code that will be used by others. They know that most changes will come back to them, as has been evidenced by decades of BSD use by companies.
And it only makes sense because if you are a company if you contribute code back you only have to write it once. If you do not you have to patch it with every release.
In the GPL case, it doesn't matter if a company makes money or not. You simply want to see changes other people made just like the BSD guy, only you have the weight of the law behind making that happen that you can use as a lever if you need to.
Insulting either one as 'religious' or 'unethical' is incredibly unseeing and idiotic.
You are the only one using those words. Once again, you are the one going to extremes. Bonch only labeled some elements of the GPL camp as extreme; and you you say honestly RMS is not?
I have been a supporter of the GPL for decades now, I am a long-time member of the FSF. I will happily state without qualification that RMS is extreme - but that is good because SOMEONE needs to be. The fact you cannot separate extreme and non extreme supporters for the GPL id a failing of yours, not of Bonch.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
AC is a moron.
I have contributed a patch to fix your comment in accordance with the GPL.
The really amusing thing is he never accepted the patch, so he's not a moron. That leaves only you with the patched version stating you are a moron...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It is only a matter of time until they decide not to contribute anything anymore.
People seem to keep coming up with this argument against BSD in general, but it makes no sense.
The vast weight of evidence, and common sense, tells us that Apple will keep giving back - even if the only motivation were greed.
Because it's a LOT cheaper to use an open source project where you simply take in updates as they happen. If you make secret patches, that means you don't write the code once - you have to massage it with EVERY release of the open branch in order to properly merge back in your changes.
A truly greedy bastard would give back EVERY change they ever made, so they could diabolically keep using the open source code base but have others test any future changes to the whole code base against the changes they made. BWA-HA-HA.
Only fools would keep any changes made that were not absolutely necessary to keep secret.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I thought that Microsoft's TCP/IP stack hasn't been based on BSD since Vista, when they pretty much moved to Teredo - which one can think of as UDP/IPv6. Before that, Microsoft too was using BSD's TCP/IP.
Yes, but LLVM is modular, and module boundaries are documented (as well as being designed for reuse). So something that can only be done by accessing "internals" on gcc, can be easily done in terms of public API on Clang.
Something I've never understood - how does a low level virtual machine become the basis of a compiler? AFAIK, there are no virtual machines in GCC, Visual Studio, or older compiler platforms from other vendors. So what caused Apple to go w/ that option here?
Did you actually look at those benchmarks?
Yes, did you?
The only case where it was not very close was, as I stated originally, where openMP was involved. It's not very surprising that being unable to make use of parallel processing on a multi-core system will set you back in any benchmark.
It's right there in the text below the graphs.
I'm very sorry that pointing out how to read benchmarks has caused you such internal angst you felt compelled to respond three times...
I'll let you have the last response since if you can't even read simple performance graphs, what good would it possibly do me to read any further response you might have?
I am not any kind of "Apple Fanboi". I simply know what the hell I am taking about, unlike you.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Programs compiled with Clang do not use LLVM at run-time, for optimizations or otherwise.
I for one, welcome our clang compiled overlords.
120 characters ought to be enough for anyone
I voted for Clodos...
Lemon curry???
I think GCC is a bit blindalleyed here. Undocumented internals are not so big problem when there is no comparable alternative. But - project is strong, without doubt. No reason to not pull over.
C++ as an health/longevity argument is a bit doubtful. But, I am obviously biased there :).
http://opencm3.net, http://www.nongnu.org/gm2/
If you're interested, take a look at the talk by Hal Finkel at EuroLLVM a couple of weeks ago. I believe there are actually three vectorisers in progress for LLVM, but the one Hal works on is particularly interesting because it approaches the problem with a very general solution, while the GCC version just transforms hard-coded patterns. I'm not sure if this code made it into trunk just before or just after 3.1 was branched, but I believe the plan for 3.2 is to have it along with a pattern-matching approach, which should autovectorise a superset of the cases GCC handled (which isn't really anything to brag about - I can think of four C/C++ compilers off the top of my head that do a better job than GCC at this).
Oh, the other nice thing about this stuff in LLVM is that it's target-independent. LLVM supports arbitrary-sized vectors in the IR, along with a fairly rich set of operations, and target back ends just map these to real instructions. Once autovectorisation is done once, it can be used with AltiVec, SSE, NEON, and so on with some very minor tweaks (basically just adjusting some heuristics that decide when it's worth bothering with).
I am TheRaven on Soylent News
There are two things in the GPL that make companies nervous. One is the patent grant, the other is the revocation clause. It is possible to discover that the product that you are selling 100,000 instances of a month violates the GPL, and have your license instantly revoked. Getting the license granted again requires explicit interaction with the copyright holder (just getting into compliance does not make the license valid again), so if you can't get hold of every copyright holder then you have to stop distributing your product or face massive liabilities.
and
As an example: gcc just _might_ infringe on some patent that Apple holds, or there might be not totally unreasonable reason to make such a claim. Assuming that Apple has no intention of suing anyone over such a patent, with GPL v2 that is neither a problem for gcc, nor for Apple, nor for Apple distributing a GPL v2 licenced gcc compiler.
But with GPL v3, if there is such a patent, then Apple is not allowed to distribute the compiler without granting everyone a patent license. Now let's say Apple sues company X over infringement of patent Y, totally unrelated to GPL and gcc. And X figures out that gcc infringes on patent Y. And therefore Apple should have given everyone, including X, a license for that patent. Can you imagine the legal nightmare this could cause? Now if you are a lawyer for Apple, and you were asked whether Apple should distribute gcc 4.6, surely you would check the GPL v3 license and think of such things and tell the developers who want to distribute gcc that there is a significant legal risk.
I think the move to llvm/clang is great and glad to hear that most packages now build with it (I had already found that to be true.) However, the one downside is that there is only C/C++ available. No Fortran (and a few others) that are available as front-ends to gcc. I do realize that LLVM can be used as a replacement backend to gcc but you are still left with the GPL.
Does anyone know if there is work on a native Fortran front end for LLVM?
That's not the job of GCC. That's the job of additional tools that work with the files.
These additional tools still need a parser. The obvious way to make additional tools that parse the source code into a syntax tree exactly the same way as GCC, including GCC's extensions to the languages that it implements, is to use GCC's parser. Do ctags and cscope implement all of GCC's extensions correctly?
Here is a link to Clang's reason for creation/existence even though GCC exists. It even mentions a few reasons people might prefer to use GCC. http://clang.llvm.org/comparison.html#gcc
What's the prospect for Clang gaining in-tree support for OpenMP?
Last week, someone posted a set of patches that added OpenMP support to clang 2.9 and relicensed them under the UIUC license so that they can be included in clang once they've been brought up to date. So far, no one has done this, but if there is sufficient interest someone probably will.
Also for clang and fortran?
Clang is a front end for C-family languages. Fortran is not a C-family language. It will therefore not ever be supported by clang. Apparently some people are working on a Fortran front end for LLVM, but since I have no Fortran code I have not really been following their progress.
I am TheRaven on Soylent News
The problem is that they don't need to do it the exact same was as GCC. They need to do it based more on the language (C, C++, D, A, B, Java, Modula, etc),
If the compiler is GCC, the language is GNU C, which is a superset of standard C, or the language is GNU C++, which is a superset of standard C++. So the parser needs to accept the GNU C and GNU C++ languages. I thought proving that two parsers accept the same language was halting-complete.
Bloating the compiler to generate the additional output information - which will be very specific to each IDE - makes no sense.
True, which is why have suggested making the compiler more modular so that its parser can be reused by either the compiler, which needs "useful information for the internals", or an IDE, which needs "something useful for the IDE to provide useful functionality for the user." The GCC team has steadfastly resisted making GCC more modular and more maintainable for fear that a non-free IDE might use the output of its parser.
You can go through the GCC development mailing list archives to find many people (including GCC steering committee members) citing RMS explicitly forbidding features that would let GCC be used as part of a proprietary compiler (eg. dumping the internal representation or reading back an IR dump). Since LLVM and Clang started gaining steam a few years ago some of those decisions have been reversed, allowing eg. the plugin system of newer GCC versions.
MacPorts is not a port of FreeBSD's ports collection or pkg. Have you ever used FreeBSD before? MacPorts is closer to portage than it is to FreeBSD ports.
Nope...you are clearly wrong.
Yes, I have used several versions of FreeBSD, NetBSD, OpenBSD. Based on you being an Anonymous Coward, its also very clear that you are a troll just trying to start a baseless argument designed to illicit a negative reply from me. Portage is a Linux based package manager made popular by the Gentoo distro of Linux. The UNIX core running under OS X is BSD based. Mac"PORTS" is based off PORT in FreeBSD. If you had any real experience in *nix *nux based operating systems you would know this and would have replied as a real person and would have backed up your argument with some actual facts.
Here is the most obvious citation from Wikipedia, where is clearly states MacPorts (formerly DarwinPorts) is similar in aim and function to Fink and the BSDs' ports collections (McMillian, 2002):
----McMillian, Allistar. "MacPorts." Wikipedia. Wikimedia Foundation, 05 Oct. 2012. Web. 15 May 2012. http://en.wikipedia.org/wiki/MacPorts.
I have 416 ports installed on my Mac from MacPorts. They all built fine.
What version OS X? What version of XCode? When was the last time you updated or rebuilt your entire base?
Keywords for the NSA overthrow oppressive regime true believers marathon Manhatten the financial district blueprints I
good software
What is that "good software" that you are talking about?
Contrary to the popular belief, there indeed is no God.
And the user will be completely confused about the whole thing, because that "definition" explains absolutely nothing, and gives no information about possible variations of things that affect the macro definition (if, by any chance, anything is conditional). Better yet, plenty of modern libraries have a layer written in this very style.
So my position on this is still:
1. The only solution that actually helps the developer when dealing with complex system of libraries is plain old documentation, where those things are explained in plain English (or whatever language the programmer prefers). One does not need IDE to do that -- middle button is usually more than sufficient.
2. If programmer needs tools to navigate declarations and macros in his own code, he is too disorganized to either remember what he is doing, or document his work in a way that he can understand. What means, the project already accumulated massive numbers of mistakes and must be abandoned as unmaintainable.
Contrary to the popular belief, there indeed is no God.
Run time optimizations can be (are?) a very bad idea in a kernel, where very often the exact predictability of execution paths makes the difference between a working kernel and a misbehaving one.
Well, with Clang/LLVM you can compile the kernel straight to the target architecture with run time optimization turned off, as well as building what else you want, for instance your applications, with run time optimization turned on. Easy as customizing your Makefiles.
Roberto
s/or just being offhand/or AREN'T just being offhand/
-- I ignore anonymous replies to my comments and postings.
You are trying new arguments now.
I am not "trying" anything.
You will only succeed in boring the recepient into not responding and thinking you are some kind of zealot/lunatic.
I do not argue with stupid people to convince them -- what use can I possibly have for an idiot that agrees with me? I argue with them to make it clearly visible to everyone else, how stupid those people's positions are.
First of all you're assuming that everyone writes the same cluttered non-local 1980s C code as what you have pasted.
I have pasted a kind of code that is usually found in system libraries that you all love so much.
They don't. Most of us who do systems level code are more than capable of using modern idomatic C++
"Idiomatic" (this is how it is spelled) means "Full of copy-paste from cookbooks" when applied to programming language use.
that fits the usecase model of Visual Assist / VS / Source Insight tooling. If you need to refactor code, there is simply no alternative to using a featured IDE toolset (if you care about productivity)
Most of the programmer's work is not messing with working code, it's writing new code that uses existing interface and incremental implementation of new functionality in existing project. Those kinds of work benefit from clean and clearly documented interfaces.
Apart from interleaved comments in the source code, most source level documentation is no longer than a quick sentence or two (if you're lucky) above the function definition. And guess what... you need the goto symbol functionality for that too.
Comments in the code are for people who modify that code -- they describe how things are implemented. At best, some useful interface documentation is included near definitions of functions and methods, however in a large project it's unmanageable, and distracting for the user who tries to understand how things are supposed to be used.
Or.. Just a thought.. he could be simply navigating code he wrote 2 years ago in order to find and fix a bug.
If a single bug is spread across interfaces, you have a fundamental problem of excessively tightly coupled code, and for every bug you know and are trying to fix there are many that you don't know about. In other words, it's shit code.
Are you incapable of enumerating thousands of valid usecases where your blanket assumptions fail?
I am incapable of thinking about "use cases" when my work is to make sure that the code always works as specified. People who operate on "use cases" are one level above those who single-step through everything they wrote in the attempt to understand how it actually works.
And *YOU'RE* the one complaining about "if it compiles ship it" culture (which is actually unrelated to using IDEs and tools). How ironic.
When I (or any decent programmer) write code, I make an assumption that it WILL be compiled and shipped once I write it, so I better have to do it right at once, and avoid all kinds of guesswork.
Then, of course, I compile, run, look through it, give it to others for review and verification, and by the time it reaches QA, everyone involved has a good idea why it is correct. After that, occasionally, something still goes wrong, and everyone learns where his (and my) reasoning was faulty. Somehow, the usual development cycle ends up going faster than with thousands of Shakespeare monkeys drowning in a sea of bugs.
Contrary to the popular belief, there indeed is no God.
I think that the GPL should be changed so that distributors could keep the source closed and copy-protected for 4 years.
This would allow them to make much more profit, thus attracting many more companies to GPL software. Then after 4 years
that code becomes public. I think this would increase the amount of available free code.