Using LLVM As The Compiler Within Fedora?

[XorEaxEax]

Not likely. Most language extensions in GCC are legacy stuff. It's hard to get new extensions in, because most extensions are stupid and are just little tweaks to turn a 4 line piece of code into a 3.5 line piece of code, and the developers have since wised up.

Says you, and if there are extensions which are not being used then they are not causing problems. Again extensions are added in all compiler toolchains, those who are really useful get widely supported and/or standarized.

There's no reason to use those. Use the standardized CPU intrinsics. (Yes, they are standardized by Intel/ARM/IBM.)

Iirc the code needed to run on architectures with different/without vector unit hardware aswell, also vector insintrics map directly to instructions and even if they are standarized the insintrics in question differ from architecture to architecture and also within architectures like with MMX, 3dNow, SSE(X) for x86/64, XSCALE/DSP stuff for ARM etc.

If they want to target MSVC 2010, then no, they should not.

Obviously, that was hardly the point.

Should programmers not use Win32 APIs if their OS (Linux) doesn't support them fully?

Huh? The logic of this sentence escapes me.

And not just random extensions (it has an unfortunate number of those too) but is being used as a testbed for features that will be proposed to the committees.

Same goes for every other compiler, LLVM/Clang is no better nor worse in this regard.

Which is one of the reasons why dipshits who think Clang is just "Apple crap" are dipshits. Clang has a LOT of incredible benefits over GCC.

Which is one of the reasons why dipshits who think GCC is just "FSF crap" are dipshits. GCC has a LOT of benefits over Clang/LLVM. Better performance of the generated code, better frontend, better code compability, more target architectures, a high level of support from large corporations in the form of full-time hired developers...

The fact that it can't compile every random low-quality FOSS crap package, or the fact that it does not _yet_ optimize as well as a much older compiler, is of little importance to some users.

And to other users it is of importance, what is your point? And stop with the generalizations such as 'low-quality FOSS crap', you really come across as a frothing by the mouth asshole, Apple and BSD hasn't been able to switch fully to Clang/LLVM yet and they are dying to do so and the reason they haven't is not because 'it doesn't work with some random package' out there. It still fails on a lot of code, I know, I use it alongside with GCC at work (we want our code to compile without warnings on several compilers). It is also rapidly improving.

The fact that it's massively easier to alter and extend, that it provides incredibly more logical error messages, that it allows much richer plugins and non-compiler uses than GCC, that it was designed to be easy to use for editors and tools

Oh cut the propaganda, it has better error diagnostics (best of any compiler I've used actually) but it's not 'incredibly' much better, on plugins I see no difference with LLVM over GCC, the LLVM project even maintains a GCC plugin called dragonegg, a compiler backend plugin so that it can use GCC's much more mature frontend. You are just sounding like a gushing schoolgirl or some infomercial with all these 'incredible' this and 'incredible' that.

editors and tools (which are more important than the compiler itself, IMO,

Not me, I can do with a simple editor but I require a good compiler toolchain, not sure what you mean by tools.

[kraftman]

And not just random extensions (it has an unfortunate number of those too) but is being used as a testbed for features that will be proposed to the committees. Which is one of the reasons why dipshits who think Clang is just "Apple crap" are dipshits. Clang has a LOT of incredible benefits over GCC.

While it's currently only a testbed it just proves it's apple's crap for now. Benefits like what? Supports more architectures, produces faster code or compiles more stuff, perhaps? None of this and the benefits you mentioned later are just not comparable to the ones mentioned here.

The fact that it can't compile every random low-quality FOSS crap package, or the fact that it does not _yet_ optimize as well as a much older compiler, is of little importance to some users.

Just dipshits think it's not so important to compile such packages and while GCC can the problem maybe lays in low-quality bsd licensed apple's crappy compiler?

The fact that it's massively easier to alter and extend, that it provides incredibly more logical error messages, that it allows much richer plugins and non-compiler uses than GCC, that it was designed to be easy to use for editors and tools (which are more important than the compiler itself, IMO, and in the common opinions of anyone who actually maintains large and complex codebases)... these are why Clang is so awesome.

It will be awesome when it will be able to compile the Linux kernel, all of the packages that GCC compiles and when produced code will be faster or at the same level. Currently it's just apple controlled compiler that tries to catch up.

[ciplogic]

Not me, I can do with a simple editor but I require a good compiler toolchain, not sure what you mean by tools.

It is true as much as even John Carmack said that tools to do static analysis are crucial for code quality. Refactoring tools are most of times missing in C++ realm. Maybe LLVM/CLang if integrated in an OSS stack, may offer good enough refactoring tools (or maybe GCC would offer a better parser API).
I think this is what he is referring about.
Anyway, I do think as GCC is the backbone of too many software, I fully agree with you, LLVM make little sense out of some specific targets and OS X realm, maybe as a better code generator for Mono runtime.

[curaga]

Yep, and Clang doesn't yet do static analysis for C++. Eagerly waiting for that to happen though.

[DaemonFC]

So to sum it up, Fedora isn't using LLVM because:

1. It wouldn't compile a lot of packages, including the kernel.

2. When it does work, it tends to generate worse output than GCC.

3. It generates less useful debuginfos.

As well as (implied)...

4. Let's not introduce Apple dependencies on a Linux distribution. Apple makes money by court injunctions against competitors, not making better products. Why would we want free software to depend on a rent seeking patent troll like Apple?

[allquixotic]

XorEaxEax: The essence of your posting is, that the gcc language set has to be treated like a language standard (which it is NOT; it might barely be an unofficial one). So every programmer that uses these extensions, forces the users to use that compiler too and depending on your definition of freedom, this makes the users less free than before (example: the BSD guys). This is equal to like using a non standard library in your program (think of early KDE days: KDE was free, Qt was not).

It's impossible to reduce anyone's freedom by writing or using free software code and free software ideas. Nothing is preventing llvm/clang from implementing a gnu99 mode, just like Firefox and Chrome implement an IE Quirks mode that tries hard to deal with horribly-programmed websites that were coded to IE 6's behavior. And frankly, I think Firefox and Chrome are a superior browser compared to IE as a result of their wide-ranging compatibility. Can't Clang do the equivalent for a compiler? There aren't any patents on the GNU C extensions afaik.

I claim that it might be very convenient for the programmer to choose such extensions, but as I said, there is a price.

And I claim that it might be very convenient or desirable for a user to choose a certain compiler, but unless you're willing to support the (free as in freedom) code that's out there, there is a price (i.e., the cost of implementing those non-standard extensions in your compiler).

Basically, I could sit down for about six weeks and write an absolutely minimal C compiler that just baaarely supports C89 (and without any of the optional features of the C89 standard, and with a huge amount of variance in the behavior of undefined behavior situations compared to existing compilers such as gcc). I could claim full C89 standards compliance. But in practice, most large programs have at least SOME code that relies upon undefined behavior if you strictly go by what the standards say. So if my crap compiler decides to, I don't know, panic the kernel whenever it finds undefined behavior, that's perfectly fine with the standard. But it wouldn't be perfectly fine with me as a user.

If I then show you my standards-compliant compiler and ask you why your perfectly C89-compliant code panics my kernel, would you then be obligated to fix your code so that, when compiled with my compiler, it works properly? No, I don't think I'd be entitled to ask that of you, as the compiler author.

The same situation is true for LLVM and supporting GNU C extensions. If "you" (as someone who values LLVM/Clang) want to improve your compiler-of-choice's ability to compile correctly-operating programs that were written by third parties which do not particularly value your compiler compared to any other, you have two options:

1. Submit patches to the application code to make it compatible with your compiler, and follow any directions given to you by the application maintainer to implement e.g. conditional compilation directives, so you don't screw up the performance or functionality of existing compilers that they target.

2. Submit patches to your favorite compiler's code to make it compatible with your application, by mimicking the behaviors of the officially supported compiler(s) that cause the program to successfully compile and run.

You should not expect someone else who is maintaining a free software project to do this work automatically for you, especially if they have no particular interest in the use of your favorite compiler. It is not your prerogative to place work on others' shoulders just to satisfy your own personal demands. If you want it done, the best way is to do it yourself, or work among a group of like-minded peers and developers who are interested in the same goal.

I just think that this whole argument about standards compliance is missing the point. "Standards" are an illusion in software. There is always going to be some loophole, some piece of undefined behavior, some detail left unspecified, in every human-created standard, and in every human-created program code. As the complexity of the standards and the complexity of the code together increase, the probability of hitting said undefined behavior asymptotically approaches 1.

So, assuming that X compiler is going to have some issues compiling or producing correct binaries for Y program, coming down from on-high and citing standards isn't going to be an effective approach, because standards aren't the only thing that can cause incorrect behavior. Instead of clinging to "but the standards!", you need to get involved in the actual nitty-gritty politics of the situation, and try to convince people that they SHOULD care about your personal compiler, and they SHOULD want to help you patch their application code (or, respectively, your compiler's code) so that the compiler plays nicely with the application and vice versa.

Compatibility is not a one-way street, especially in the free software world; and there is no magical appeal to authority that can be used to convince others that they ought to do what you say. Instead, you need to build bridges, form alliances, and create mindshare for your agenda. If you can't do that, maybe it's because, oh I don't know, your compiler is substantially slower than the de facto solution, so nobody thinks it's worth worrying about right now?

Well, there's that, and there's also the notion that GPL purists (or even those who aren't strictly GPL purists but just dislike liberally-licensed free software licenses) might resist LLVM just on principle. And I think that is an entirely fair thing to do, because it brings to light a real disagreement and a material discrepancy of opinion, something that you can't avoid by just waving the standards flag around like a lunatic.

[yogi_berra]

Just stop trolling,

Yes, why don't you?

first off the extensions are not platform specific, you can use them on Windows aswell

Right... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?

[kraftman]

Right... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?

I'd love to see GCC being Linux only, but while it's not you should be grateful you can even use it on Windows. If you have something against GPLv3 blame those who're using incompatible licenses. It's their problem they're incompatible with GCC and they're closed. Open Source GCC that uses the best license cannot be closed, can it? I also recommend you to go at microsoft.com and ask why visual studio is platform specific.

[XorEaxEax]

Right... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?

??? No, these extensions are not patented, other compilers can and DO add them. Other compilers also add THEIR OWN extensions which GCC does not support, Clang/LLVM has their OWN compiler extensions, Microsoft Visual Studio C/C++ has their OWN extensions.

And how the **** do you get from a specified extension which ANYONE can implement to claiming that it is CLOSED????? Not to mention that both GCC and Clang/LLVM are both free to download and use, no matter what platform you are on.

You are a troll, none of your statements have any reasoning behind them. It's like listening to a 5 year old throwing a tantrum.

[DaemonFC]

Yes, why don't you?



Right... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?

As has been explained many times.

The GPL is about END USER FREEDOM and stopping unscrupulous middle men from taking that freedom away. The BSD license is about DISTRIBUTOR freedom, specifically, giving the developer the freedom to take away the user's freedom.

When the Apple meat puppets over at FreeBSD call their license more free than the GPL, this is what they mean.

As a user, I have to say I'd rather side with the license that guarantees freedom for me. Of course, developers that just want a free handout don't like the GPL, why would they? It stops them from abusing the end user and burying free software inside proprietary software.

Back to LLVM. If it was better than GCC for the purposes of building binary object code, then there's no ethical problems with redistributing it. But I would hope that someone would fork it and wrap the GPL around it to prevent freeloading proprietary software from making use of those improvements.

There's nothing wrong with using software under a permissive license, though permissive licenses are usually a form of corporate welfare. (Either the project is ran entirely by some corporate entity or there's a horribly mistaken programmer that is working for free to help build the next OS X.)