Weekly Edition
Return to the Development page
| ||||||||||||||||
|
| ||||||||||||||||
LLVM 2.6 released
Hi LLVM Friends, Fans, Followers and Fanatics, LLVM 2.6 is live! You can download it here: http://llvm.org/releases/ and read about it here: http://llvm.org/releases/2.6/docs/ReleaseNotes.html This release includes approximately 6 months of development that provide major enhancements and new features over the LLVM 2.5 release. This includes significantly better X86-64 code generation, link-time optimization support for ELF systems (with 'gold' linker), new code generators for the MSP430, SystemZ, and BlackFin architectures, support for multithreaded code generation and optimization, OProfile integration for the JIT, support for SSE 4.2, ARM V7 support (including Thumb2 and NEON), Ada2005 bindings, many improved optimizations, bug fixes, and extensions and enhancements to the runtime API. Please see the release notes for more details. A major highlight of the LLVM 2.6 release is the first public release of the Clang compiler (http://clang.llvm.org), which is now considered to be production quality for C and Objective-C code on X86 targets. Clang produces much better error and warning messages than GCC (http://clang.llvm.org/diagnostics.html) and can compile Objective-C code 3x faster than GCC 4.2 (http://clang.llvm.org/performance.html), among other major features. In addition to Clang, the LLVM project has grown a number of new LLVM sub-projects, including: - compiler-rt: Compiler runtime library (http://compiler-rt.llvm.org/) - KLEE: Symbolic Analysis & Test Case Generator (http://klee.llvm.org/) - DragonEgg: "llvm-gcc" plugin for GCC 4.5 (http://dragonegg.llvm.org/) This release also includes the early start of a new "llvm-mc" project (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc), which aims to auto-generate a suite of assembler, disassembler, and other machine code technology from the LLVM target descriptions. One of the things I'm really excited to see is the number of external projects that are applying LLVM technology in interesting new ways. The release notes lists two Ruby implementations (Rubinius and MacRuby), the Pure language, the LLVM D Compiler, the Roadsend PHP compiler, Unladen Swallow (Python) and LLVM-Lua. These projects show an amazing breadth of different languages adopting LLVM as their shared optimization, code generation, and JIT technologies (depending on the project). Besides open source projects, there are a number of commercial organizations applying LLVM in innovative new ways (http://llvm.org/Users.html), and LLVM is being used for a wide range of research projects published at the top academic conferences and journals (http://llvm.org/pubs/). It is truly exciting to see what people are doing with LLVM! Finally, we just wrapped up the third annual LLVM Developer's Meeting, which was a great opportunity for LLVM people to meet face-to-face and exchange ideas. The event web site (http://llvm.org/devmtg/2009-10/) includes slides and videos for most of the talks. We send many thanks out to Apple, Google, Adobe and Qualcomm Incorporated for sponsoring the event! This release would not be possible without our volunteer release team. Thanks to Tanya Lattner, Pawel Worach, and Nick Lewycky for their work to qualify and shepherd the release. If you have questions or comments about this release, please contact the LLVMdev mailing list! -Chris LLVM 2.5 Release Announcement: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-Mar... (Log in to post comments)
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 14:32 UTC (Mon) by coriordan (guest, #7544) [Link]
So now there's a free software module that can be used with gcc and it boasts a load of improvements. That's great.
And what if it wasn't free software? What if someone made a proprietary module would produce 20% faster code? Would the big distros all compile their code using the proprietary module?
That would be a big setback. They'd be giving you the freedom to modify the software, but when you do so and recompile, you'd have a slower program. Tryin to out code them to erode the temptation to use proprietary software would be a lot of work. That's what FSF is being so careful about with the GCC pluging exception, and why it justifies spending some time to get it right.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 15:12 UTC (Mon) by trasz (guest, #45786) [Link]
So basically, you're saing that it's wrong that people can buy better things for money instead of being forced to use a worse - but free - versions, and FSF is working hard on making this as hard as possible?
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 15:22 UTC (Mon) by tajyrink (subscriber, #2750) [Link]
I don't see much point in what he's saying (distros probably won't switch to proprietary stuff), but he was not talking about money, but closed vs. open (equals to proprietary vs. free).
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 15:33 UTC (Mon) by MisterIO (subscriber, #36192) [Link]
If a closed source software is better than an open source one, most people will choose the closed one and so they should! Open source usually wins because, through the collaboration of many individuals, better software is built, even better than the closed one. If you strive for opennes forgetting about quality, be ready for the extinction of your project.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 16:32 UTC (Mon) by Doogie (guest, #59626) [Link] Open source usually winsNot really. In terms of overall market share, very few software categories are dominated by Open Source software. The only one I can think of off the top of my head is Apache's dominance of the HTTP serving market. In operating systems, the best Open Source can muster is a distant third to Windows and OS X on the desktop (although I seem to recall Linux does better on servers). The GIMP loses against Photoshop. OpenOffice loses against Microsoft Office. etc. Don't get me wrong, I use and love Open Source, but lets not kid ourselves as to market share. Open Source makes for a useful base for companies like Apple to build high quality and popular closed source products upon, but Open Source is still a fairly small niche when it comes to interacting directly with end users.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 17:28 UTC (Mon) by drag (subscriber, #31333) [Link]
Linux and open source is much more popular then you think.
People get too caught up with what is being used on the desktop and such.
But people have to realize that the vast majority of all software is
Also the other thing to keep in mind is that computers is much more then
For example with the open source'ng of Symbian combined with Linux the
And you pointed out servers; Linux is now much more widely deployed then
I think it has gotten to the point now that more and more times customers
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 20:11 UTC (Mon) by Trelane (guest, #56877) [Link]
"In operating systems, the best Open Source can muster is a distant third to Windows and OS X on the desktop"
http://www.osnews.com/story/21035/Ballmer_Linux_Bigger_Co...
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 22:01 UTC (Mon) by coriordan (guest, #7544) [Link]
> If a closed source software is better than an open source one,
> most people will choose the closed one and so they should!
This assumes we should value freedom at zero. I don't. When I evaluate two programs, I place a high value on freedom.
Without freedom, the free software development model stops. That's bad.
The reason people like this operating system is that it does what the users want. It's not a vehicle for ads or DRM or lock-in or for being annoyed into buying an upgrade. It does what users want because at the end of the day, because everyone's been given freedom, the users have a lot of control over the direction the software develops in.
So I'll take a slower free version over a binary blob any day.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 9:42 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
>> If a closed source software is better than an open source one,
>> most people will choose the closed one and so they should!
>This assumes we should value freedom at zero. I don't.
I would still go with this, but I wouldn't just include performance in the equation. I would also include trustworthyness of the software (it is possible to get a good idea of how trustworthy proprietary software is, just as virus and trojan detection is possible), price of course and trustworthyness of the authors. Free software has an inherent advantage on all of these points, but sometimes it still falls behind overall.
Of course I don't value freedom at zero either, but software freedom is not at the top of my scale of priorities either, when there are so much more important freedoms in the world which are trampled upon daily - I find it hard to consider my minor freedoms more important than other peoples basic human rights.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 15:26 UTC (Tue) by coriordan (guest, #7544) [Link]
Your software freedom does not come at the cost of anyone's human rights, so the two don't affect each other.
And it's worth keeping in mind that free software developed in rich countries is available for people all over the world.
Who's working on software for free communication in oppressive countries? I think all of the big projects are free software. Who's putting blogging systems, news site systems, webservers, and operating systems in the hands of the people in countries without freedom of the press?
When you demand (software) freedom for yourself, you empower less-well-off people just as a by-product, so I hope people do demand freedom.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 16:00 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Of course. But I do think that one should get the priorities right. I suspect that fairer trade would do more good for those people born in the wrong place and time than software freedom, and it makes me a bit sad when I see so much lobbying effort being put into the one which could (also) have been put into the other.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 18:33 UTC (Tue) by coriordan (guest, #7544) [Link]
That's debatable. I'm a full-time software freedom lobbyist and have been for 6 years. If I wasn't lobbying for software freedom, would I be lobbying for something that more directly helps the world's poor?
I don't know.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 19:22 UTC (Tue) by coriordan (guest, #7544) [Link]
Before getting into lobbying, I was a programmer - I loved programming and it kept me happily employed. If the issues of freedom and the need for lobbyists didn't present itself, I probably would have stayed a programmer.
So rather than being a member of the lobbyist community that's being diverted from one good cause to another, I think I'm a member of the software community, diverted from one department to another.
I'm only one example, but it makes the point that I don't think we can assume that having lobbyists for software freedom is detracting from other areas.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 19:34 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Fair enough. And I suppose that lobbying on one count doesn't stop someone lobbying on the other either if they feel that interest.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 15:29 UTC (Mon) by AlexHudson (guest, #41828) [Link]
In what way does gcc's license affect LLVM?
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 21:49 UTC (Mon) by coriordan (guest, #7544) [Link]
GCC's licence (or specifically the licence of the gcc-runtime library) will only compile the metacode output of a plugin if that plugin is GPL compatible:
http://lwn.net/Articles/301135/
From the exception:
"""
A Compilation Process is "Eligible" if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process.
1. Grant of Additional Permission.
You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 21:10 UTC (Tue) by AlexHudson (guest, #41828) [Link]
You're explaining gcc plugins. What I was asking was more about why LLVM has been affected by gcc's license. Are you saying LLVM / clang is a mere gcc plugin?
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 21:54 UTC (Tue) by coriordan (guest, #7544) [Link]
The module I mentioned was a reference to the DragonEgg module (linked from the blurb on the story's entry on the lwn homepage). I don't know how much of LLVM/Clang (all? most? almost nothing?) is included in DragonEgg.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 22:13 UTC (Tue) by coriordan (guest, #7544) [Link]
Maybe I could have been clearer in my first post.
The reasons for GNU's care with gcc licence Posted Oct 28, 2009 8:17 UTC (Wed) by AlexHudson (guest, #41828) [Link]
I think saying that GCC's license resulted in DragonEgg being free software is a bit debatable. LLVM was free from the start, and deliberately not based on GCC - being GPL-compatible it doesn't need the plugin exception anyway.
I suspect the proof of the exception pudding will be in the eating 5/10 years from now.
The reasons for GNU's care with gcc licence Posted Oct 28, 2009 11:02 UTC (Wed) by coriordan (guest, #7544) [Link]
I agree.
My point wasn't that GCC caused LLVM to be free. My point was that with this proof of concept (DragonEgg), hopefully it's easier to see why FSF is so careful about GCC's licence exception and ensuring that only free software modules/plugins can be used with GCC.
If proprietary modules were allowed, it would be a disaster for free software compilers.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 16:04 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
I believe add-ons for PHP will provide useful and concrete examples for what you have in mind, right?
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 16:18 UTC (Mon) by Kit (guest, #55925) [Link]
>What if someone made a proprietary module would produce 20% faster code?
What if instead of a module, they released a compiler that was 20% faster? Would that be any different? And hasn't that been the situation at many times (icc is often said to be faster than GCC, but it has never become dominate or anything like that)?
>That would be a big setback. They'd be giving you the freedom to
As opposed to *always* having a slower program?
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 22:05 UTC (Mon) by coriordan (guest, #7544) [Link]
> What if instead of a module, they released a compiler that was 20% faster?
That would be an equal temptation for people to use proprietary software, but it would entail a way bigger effort. As you mentioned, even Intel has tried and failed.
The GCC codebase is there to be reused by anyone who wants to advance free software. If someone wants to compete against free software, there's no reason to let them use GCC as a springboard.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 23:27 UTC (Mon) by nix (subscriber, #2304) [Link]
As an aside, the question 'why would they *want* to base anything on GCC?'
could fairly have been asked eight or nine years ago, but GCC is a good bit cleaner now and might actually be a target of theft again. And the license is still there... :)
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 0:32 UTC (Tue) by Kit (guest, #55925) [Link]
>That would be an equal temptation for people to use proprietary
>software, but it would entail a way bigger effort. As you >mentioned, even Intel has tried and failed.
But doesn't that just amount to vendor lock-in? And isn't that a *bad* thing? Or is it suddenly good when employed by FOSS (and largely against FOSS)?
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 1:47 UTC (Tue) by coriordan (guest, #7544) [Link] Ah, not at all. For a start, which vendor exactly could you find yourself locked into by GCC?
The reasons for GNU's care with gcc licence Posted Oct 30, 2009 19:54 UTC (Fri) by anton (guest, #25547) [Link] The GCC maintainers. We are actually locked in there, because we use GNU C. Since the current GCC maintainers only want to support ANSI C (plus maybe the SPEC benchmarks) well, that's an uncomfortable position.Yes, I have been thinking of forking off a version that does what we need, but that would be a huge project. The Linux maintainers have similar complaints about the direction GCC is taking, but even they have not gone for maintaining their own compiler.
The reasons for GNU's care with gcc licence Posted Oct 30, 2009 21:14 UTC (Fri) by nix (subscriber, #2304) [Link]
The current GCC maintainers have a lot more than the spec benchmarks in
their release criteria. There *are* a bunch of documented extensions, and any that are actually in use by serious software aren't likely to be dropped. If the Linux kernel or glibc uses them, no chance of dropping.
This nails really tricky extensions like the statement expression
Extensions really aren't removed very often. New ones are strongly
The reasons for GNU's care with gcc licence Posted Oct 31, 2009 23:08 UTC (Sat) by anton (guest, #25547) [Link] Right, the extensions are not explicitly dropped, they are just broken or implemented badly, and bugs on them are not fixed. Instead, bug reports are closed as invalid in less time than it took to create them (e.g., PR25285), which does not really encourage further bug reports (probably a welcome side effect).extensions [...] in use by serious software aren't likely to be dropped. If the Linux kernel or glibc uses them, no chance of dropping.Ok, now that we know what serious software is, that makes the rest of us non-serious by default. And even the Linux kernel maintainers complain about GCC breakage, so the rest of us are really screwed. E.g., there are several projects that use labels-as-values for code-copying, e.g., Qemu, SableVM and Gforth. Since gcc-3.x the gcc maintainers have broken this several times in various ways. AFAIK Qemu has finally given up on using that technique, while Gforth still finds workarounds, for now. Concerning statement expressions: If they don't work in C++ (what are non-POD types, BTW), neither the Linux maintainers nor I will notice, but somehow the gcc maintainers feel that C++ and standard C are a good excuse for not repairing compiler bugs that affect GNU C (example). Concerning LTO (link-time optimization, right?), who asked for that? People are complaining about the slowness of compilation already, now linking is going to be made a lot slower as well. Great! Another "optimization" to make GCC look good on SPEC. In contrast, all the "optimizations" added since gcc-2.95 have only slowed my code down (e.g., look at slide 9 of this presentation) and required me to add workarounds (you see their effects in the 0.7.0 numbers on that slide).
The reasons for GNU's care with gcc licence Posted Nov 1, 2009 13:15 UTC (Sun) by nix (subscriber, #2304) [Link]
That was in the multi-year period when pinskia couldn't see a bug report
without closing it. He seems to have got better now (mostly 'cos everyone complained).
The reasons for GNU's care with gcc licence Posted Nov 1, 2009 13:28 UTC (Sun) by nix (subscriber, #2304) [Link]
Non-POD types are C++ types with (roughly) constructors, destructors,
member functions or making use of access control. The problem with statement expressions is what happens to temporaries when they leave the statement expression: do the destructors get called? when? We're between sequence points! Lifetime considerations like this are *critical* in C++ and they simply weren't defined for this extension.
(FWIW I don't give a damn if the compiler doesn't spend a lot of time
And, who asked for LTO? Other than everyone? Right now if you split a file
So the solution is to push as much post-parsing work as possible to link
Every high-end compiler out there other than GCC does some form of
And the results are worthwhile. Toon Moene might want to chime in here: it
The reasons for GNU's care with gcc licence Posted Nov 1, 2009 21:01 UTC (Sun) by anton (guest, #25547) [Link] Maybe you should mention which direct-threaded interpreters and which compilers you are talking about. My experience with Gforth is completely different: Despite the unsupportive attitude of the GCC maintainers towards GNU C, they have managed to at least keep the most basic part of the labels-as-values extension functional, and that's all that's needed for threaded code. Of course, they slow it down now and then in the name of "optimization", but at least it runs. You can see (slide 8, 9 in this presentation) that even old versions of Gforth (0.5.0 is from 2000, 0.6.x from 2003) work with lots of gccs, including those that have been released later than these Gforth versions. Gforth falls back to threaded code if the faster code-copying techniques fail.If you are thinking about code-copying techniques (not threaded code), these have certainly been broken by gcc-3.2 and later by reordering the code. However, these kinds of reorderings have not been performed by any gcc up to and including gcc-3.0, so I don't think they are intrinsically fragile; they would be robust if the gcc maintainers decided that they should be robust. and should probably move to doing the nasty parts directly in assembly or using GNU Lightning or something like that. It's theoretically less portable but not in practice because the threading using computed goto or whatever never works for long, so you're trading a real compiler-version portability problem that soon bites everyone for a portability problem that bites the tiny set of people not using x86, or, if you're feeling especially nice, x86/SPARC/MIPS/ARM.As you can see from the Gforth results, we would be trading portability across a wide range of architectures (theoretically all those supported by gcc, practically 8 architectures were tested before the latest release, and some more in earlier releases) and compiler versions for non-portability (your assembly solution) or very limited portability (GNU Lightning). Thanks to the portabiliy of our techniques Gforth has been available for the "tiny set of people" who use AMD64 right from the start. Concerning link-time optimization, I certainly have not asked for it, and I have never seen anyone else ask for it, either. And I guess those people who break their applications into a bunch of shared libraries (seems to be pretty common these days) have not asked for link-time optimization either. I guess it's something discussed a lot among people who evaluate compilers by their SPEC numbers, but in the rest of the world it will just make linking slower and will therefore be disabled. BTW, look at the performance of different GCC versions on Gforth. Note that gcc-2.95 is either the top performer, or close to it, while other GCC versions are often slower, sometimes by a factor of 2 or more. So much for progress. Link-time optimization is another step in the wrong direction.
The reasons for GNU's care with gcc licence Posted Oct 30, 2009 22:47 UTC (Fri) by coriordan (guest, #7544) [Link]
This point has no foundation.
Every widely used compiler has extensions. The writing of an operating system raises more questions than the ANSI working group can predict.
No kernel hacker (or none that would be given decision making power) ever suggests that the kernel should be written in ANSI C.
In addition, this is how the language evolves. There's a standard, it covers 99% of what needs doing at time of publication, and ten years later when usage has changed, it's now only covering 95% of modern needs, so ANSI gathers a group to look at what add-ons have been implemented by multiple projects, and is it possible to do that thing in a standardised way.
The GCC team would be bad compiler writers if they didn't work on useful extensions of the language to help the operating system developers.
And given that they've documented every extension publicly in full (source code), there's nothing stopping other compiler writers from making a compatible compiler. There reason no one forks GCC over this issue is that it's a non-issue. Compilers are written for developers, and the developers are not calling for a fork.
The reasons for GNU's care with gcc licence Posted Oct 31, 2009 23:44 UTC (Sat) by anton (guest, #25547) [Link] Maybe I am no developer in your eyes, but I would really love to use a fork based on the idea that optimization must preserve behaviour, including non-standard behaviour. Maybe a version based on gcc-2.95 with the new ports added and the bugs fixed. Or a fork based on the current gcc that generates code similar in spirit to what gcc-2.95 produces, by disabling some "optimizations", among other things. I don't know which approach is easier. Of course, it does not have to be a fork, I would be be just as happy with a completely different compiler that has the properties I need.In my experience the GCC maintainers make the existing extensions less useful by breaking programs that use them; and it seems that some of these programs are even operating systems. BTW, is your focus on operating systems supposed to mean that we should not be using GCC for applications or, e.g., programming language implementations (my domain).
The reasons for GNU's care with gcc licence Posted Nov 1, 2009 1:43 UTC (Sun) by coriordan (guest, #7544) [Link]
> Maybe I am no developer in your eyes
I never said that, and I'm surprised you could take that meaning from my post. (knowing only your LWN username, how could I judge you?) Either way, it wasn't my intention.
Changes in GCC are often bound to annoy *someone*, but the lack of any current fork or serious discussion of forking implies that, for the vast majority of GCC users, the GCC development team is doing an ok job of steering between progress and compatibility.
(LLVM's reason for being is about licences, not incompatibility discontent - even if they might evoke that as an additional differentiator.)
> is your focus on operating systems supposed to mean that
No. The distinction is rarely relevant, and I don't think it's relevant here. GCC is for glibc, Apache, python, etc.
The reasons for GNU's care with gcc licence Posted Nov 1, 2009 19:30 UTC (Sun) by anton (guest, #25547) [Link] LLVM's reason for being is about licences, not incompatibility discontent - even if they might evoke that as an additional differentiator.Yes, that would be a good reason to switch to LLVM for those of us who are not content with the attitude towards GNU C shown by the GCC maintainers. Unfortunately the little I have read in the LLVM bug tracker indicates that the LLVM maintainers have an attitude similar to the gcc maintainers at the moment. But competition is good, maybe one of the groups will one day compete for users based on GNU C support instead of just neglecting us because we have no other choice anyway.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 18:44 UTC (Mon) by sbergman27 (guest, #10767) [Link]
How about just competing for users by providing a better product instead of going to great lengths to implement what boils down to protectionism? If GCC's optimizations suck so badly compared to the competition, then I would say that it is that shortcoming which should be addressed. And that effort spent trying to exclude the competition, Free or proprietary, is misdirected.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 22:11 UTC (Mon) by coriordan (guest, #7544) [Link]
GCC's optimisations are top notch. Even Intel, with all the inside know-how about their own chips, can only squeeze a few percent past GCC in a few tests - and that's a single platform, single language compiler.
IIRC, Intel's compiler managed to compile just the kernel Linux - but no one uses their compiler, so we don't know if they introduced code generation bugs. On the other hand, we have GCC compiling gigabytes and gigabytes of software for the GNU/Linux distros, and two decades of testing.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 22:26 UTC (Mon) by sbergman27 (guest, #10767) [Link]
> GCC's optimisations are top notch. Even Intel, with all the inside know-how about their own chips, can only squeeze a few percent past GCC in a few tests - and that's a single platform, single language compiler.
If you say so. But if GCC is so far superior to the competition... why are you so worried about GCC modules showing you up? GCC is the hands-down best, but a proprietary module might show up out of nowhere and steal the show?
You don't sound all that confident in your product.
I'm pretty confident in FOSS. But you don't sound so.
The reasons for GNU's care with gcc licence Posted Oct 26, 2009 23:30 UTC (Mon) by coriordan (guest, #7544) [Link]
We're doing ok today, but there's nothing to say a cool new technique won't appear tomorrow.
(And since LLVM is under a BSD licence, tomorrow's competition might be a proprietary-ised version of LLVM)
...but while GCC outshines other compilers in some ways, it's slightly behind some compilers in other ways. It's an amazing success, but it's been a constant struggle to keep up this pace of development.
GCC optimizations Posted Oct 27, 2009 6:22 UTC (Tue) by brouhaha (subscriber, #1698) [Link] GCC's optimisations are top notch.That may well be true for x86, but it doesn't seem to be for ARM (or Thumb). The ARM RVCT compiler produces *much* better code than GCC. I'm not complaining about GCC, mind you. I'm very glad to have it, and I'm not about to ditch it for RVCT. I'm only pointing out that support for some target architectures still has a fair bit of room for improvement. And having more open source alternatives (such as LLVM) is certainly a good thing. In my "copious free time" I've been working on two new compilers for obscure programming languages, using LLVM for the back end. It's a lot of fun, though I don't think I'll have anything ready for release for quite a while yet.
GCC optimizations Posted Oct 27, 2009 15:34 UTC (Tue) by coriordan (guest, #7544) [Link]
Good to hear.
Just one thing that occurred to me in this discussion: with LLVM under a BSD licence, there's the possibility that LLVM will become as good as GCC (that's no problem in itself) and then someone (MS? Novell? Apple?) will take the code, add their know-how to make it better, and then publish the "best" compiler as proprietary software.
That's a realistic path for proprietary software to overtake GCC and all free software compilers - and as a slap in the face, it would have been fueled by the free software developers of LLVM and any BSD licensed projects built on top of LLVM. This danger can be avoided by making your project copyleft (GPL or another copyleft licence). This removes the danger of a big setback for free software, so I hope you'll consider it.
GCC optimizations Posted Oct 27, 2009 19:31 UTC (Tue) by niner (subscriber, #26151) [Link]
Interesting to see Novell in a list of possible companies that might take open source and
sell it as proprietary software when Novell's usual way is to buy closed source software/companies and publish it under a free license. I wonder how many more times they have to do that for people to finally grok this...
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 7:58 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Intel had to re-implement the whole compiler, due to gcc's license. Thus it is not a very good example.
How about PHP and the Zend Optimizer?
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 18:41 UTC (Tue) by coriordan (guest, #7544) [Link]
No they didn't. They could have contributed to GCC. That would have been extremely welcome and it would have helped the whole world.
Think of it this way. With the GPL, you start with the base A and let's say there are three contributors B, C, and D. The result it ABCD.
With BSD licence, B, C, and D each keep their work secret, so the world gets three compilers, AB, AC, and AD.
The result is crappier compilers, which is bad in itself and also creates less motivation for E and F to join in.
Intel chose not to help, and would only help on condition that we don't benefit from their work, but dozens of other companies are helping, so we don't need Intels non-contribution, and we do appreciate the contributions of the other companies.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 22:04 UTC (Tue) by dennisdjensen (subscriber, #25165) [Link]
You are forgetting base A. The motivation for others to join in on base A is not going to diminish,
just because 3 others had fun, and maybe even earned money on AB, AC, and AD. Au contraire.
Besides, often those 3 derived projects give somthing back, the same way e.g. Apple has given
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 22:19 UTC (Tue) by coriordan (guest, #7544) [Link]
Apple's a perfect example. They didn't want to contribute back and tried to get away with publishing binaries. When the GCC devs refused this and pointed to the GPL, Apple then contributed their software as free software.
If they could keep their changes proprietary, then A wouldn't get any worse, but it would always be second best, so who'd use it? That, and it would break the the "same rules for everyone" principle that causes multiple companies to contribute to free software projects.
How many companies contribute to GNU/Linux? And how many to FreeBSD?
Companies are afraid to contribute to the free core when they know that their competitors can take those contributions, build on top of them, and not contribute back. Again, Apple's an example: they contribute back to FreeBSD only the stuff that they don't want to have to maintain separately. Crumbs.
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 23:22 UTC (Tue) by foom (subscriber, #14868) [Link]
> Again, Apple's an example: they contribute back to FreeBSD only the stuff that they don't
> want to have to maintain separately.
So: how do you explain LLVM, then?
The reasons for GNU's care with gcc licence Posted Oct 27, 2009 23:43 UTC (Tue) by coriordan (guest, #7544) [Link]
Every generality has occasional exceptions :-)
Maybe they've never gotten over that they had to contribute back to GCC so now they're supporting a compiler that might become something they can contribute to only as it suits them? Who knows?
LLVM 2.6 released Posted Oct 26, 2009 14:37 UTC (Mon) by joseph_mayer (guest, #61137) [Link]
Instead of releasing new alpha quality projects (DragonEgg)
with every version, maybe they should concentrate on making the existing code usable.
LLVM 2.6 released Posted Oct 26, 2009 15:42 UTC (Mon) by MisterIO (subscriber, #36192) [Link]
There hasn't been a big user base of llvm till now, simply because the only people who could be interested where other projects that could use their infrastructure to build their own projects. For example, did anybody actually use llvm-gcc? For what? At most, just to try it, because there weren't any other reason to do so. Now, with clang, their direct(that is, which uses their bare products) user base is sure to grow, so they will probably(and hopefully) have to start working on stabilizing their releases(which means x.y.z versions).
LLVM 2.6 released Posted Oct 26, 2009 18:52 UTC (Mon) by azz (guest, #371) [Link]
Yep -- the C toolchain for the XMOS concurrent microcontrollers is based on llvm-gcc, so that's a real shipping commercial product using it.
LLVM 2.6 released Posted Oct 26, 2009 19:19 UTC (Mon) by Adi (guest, #52678) [Link]
AFAIK FreeBSD is planning to switch to llvm/clang from gcc.
LLVM 2.6 released Posted Oct 27, 2009 1:25 UTC (Tue) by MisterIO (subscriber, #36192) [Link]
Yes, as I said, clang not llvm-gcc.
LLVM 2.6 released Posted Oct 26, 2009 21:05 UTC (Mon) by mosfet (guest, #45339) [Link]
Apple ships it with Xcode on every OS X DVD. It is used to compile some pieces of Snow Leopard.
LLVM 2.6 released Posted Oct 26, 2009 23:13 UTC (Mon) by trasz (guest, #45786) [Link]
LLVM is already very usable - clang is able to properly compile almost all of the FreeBSD codebase.
LLVM 2.6 released Posted Oct 26, 2009 15:48 UTC (Mon) by baldrick (subscriber, #4123) [Link]
I started the dragonegg plugin because I need it. Even better, it is
interesting and fun! I'm just scratching my own itch here. I'm sorry you are having trouble with the base LLVM project. But you need to understand that dragonegg is not part of some LLVM master plan, it's just some guy starting a project off his own bat and Chris mentioning it in the release announcement because he thinks it is interesting. That's open source for you. As for the problems you've had with LLVM - please tell the LLVM developers about them. You may or may not get a helpful response, but there's a good chance the issue will be resolved once they are aware of it.
LLVM 2.6 released Posted Oct 26, 2009 16:10 UTC (Mon) by kragil (guest, #34373) [Link]
Yay for open source! (That is me saying: I like what you do.)
LLVM 2.6 released Posted Oct 26, 2009 16:27 UTC (Mon) by Kit (guest, #55925) [Link]
How does DragonEgg compare to llvm-gcc? It seems that they're fairly similar from an external view, although they accomplish it via different means.
LLVM 2.6 released Posted Oct 27, 2009 9:54 UTC (Tue) by baldrick (subscriber, #4123) [Link]
DragonEgg is two things: a port of llvm-gcc to gcc-4.5 (llvm-gcc is based
on gcc-4.2) and a redesign as a gcc plugin. The advantage of it being a plugin is that it can work with an unmodified gcc (currently this is not the case: a small gcc patch is required; but in the long term no patches should be needed).
LLVM 2.6 released Posted Oct 26, 2009 16:14 UTC (Mon) by rsidd (subscriber, #2582) [Link]
I find llvm perfectly usable, and useful, as a C compiler. But the other projects look even more exciting, if anything -- and many of them are being done by third parties who, apparently, find llvm a very clean and adaptable base to build on. I'm particularly excited by Unladen Swallow (Google's python implementation).
LLVM 2.6 released Posted Oct 26, 2009 17:04 UTC (Mon) by robert_s (subscriber, #42402) [Link]
Ooh exciting!
I didn't realize we were nearing another release.
I would like to see LLVM pay more attention to (and perhaps incorporate) bindings such as llvm-py http://mdevan.nfshost.com/llvm-py/
I know some bindings have already been incorporated. Some of us can only cope with one layer of mega-complex programming at a time and having to speak in STL on top of it all can be a bit much.
LLVM 2.6 released Posted Oct 26, 2009 18:46 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
So LLVM is basically aiming to become a universal, language-agnostic optimizer, code generator, and JIT platform? Intriguing goal. I like the idea very much. And it seems LLVM is, in some ways, outperforming GCC's own optimizers and code generators for some platforms.
I just wonder how long it might take before GCC is eventually reimplemented as a front-end to LLVM? Not in the "forked project" sense of CLang, or in the "plugin module" sense of DragonEgg, but in the full-on, entire-project-migration sense of the move to the EGCS codebase?
GCC right now supports many more frontends, and many more backends architectures, than LLVM. But, if LLVM's core capabilities continue to improve, how long might it be before the projects merge to some extent?
LLVM 2.6 released Posted Oct 26, 2009 23:17 UTC (Mon) by trasz (guest, #45786) [Link]
What would be the purpose of reimplementing GCC as a front-end to LLVM, besides backward-compatibility with code using non-standard language extensions? And even then, wouldn't it be better to just add support for these extensions to clang?
LLVM 2.6 released Posted Oct 26, 2009 23:20 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
GCC has more frontends. GCC has more backends.
I checked the GCC development list, and apparently there is talk among the devs about possible merging, down the road.
LLVM 2.6 released Posted Oct 27, 2009 11:53 UTC (Tue) by gmaxwell (subscriber, #30048) [Link]
Considering that Apple employees aren't even allowed to look at mailing lists that might contain GPLv3 code I don't think any LLVM/GCC merger is likely.
For some, the removal of the licensing requirements is /the/ reason that LLVM is interesting. For example, Adobe has a C->Flash compiler that uses llvm-gcc so they can add their own proprietary optimization passes and backend code generation.
LLVM 2.6 released Posted Oct 26, 2009 20:40 UTC (Mon) by meyert (subscriber, #32097) [Link]
"A major highlight of the LLVM 2.6 release is the first public release of
the Clang compiler (http://clang.llvm.org), which is now considered to be production quality for C and Objective-C code on X86 targets."
I guess it still doesn't compile the linux kernel, because of fancy gcc extensions?!
|
|
|||||||||||||||