Slashdot Mirror

Writing a gtk-to-Qt translator say re-using the LLVM frontend would be a very nice Ph.D. project :)

No it wouldn't. I doubt that would even be a publishable paper in a decent conference. (I appear on both http://llvm.org/developers.cgi and http://llvm.org/pubs/ )

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.

The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").

So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.

The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").

So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.

The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").

So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.

The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").

So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)

You can find tar archives here

...More like the barber shows you the cool new shaver that you didn't understand and that he helped design.

An interesting exercise is to compare the internals of Clang, written in more modern C++ versus gcc, written in C, and to decide for yourself which one you'd rather maintain.

http://llvm.org/svn/llvm-project/cfe/trunk/

http://gcc.gnu.org/viewcvs/trunk/gcc/

Note that Clang is written in modern C++ and is also faster than GCC.

One benchmark shown is that clang loading a parse tree of 'precompiled headers' is almost the same time as it takes to just compile the headers.

FWIW, I'm switching to Clang wherever it is supported because of all of the regressions in GCC for vectorization in C and C++ since GCC 4.2

The TIOBE language popularity index says Ada is holding steady in 16th place - actually up from 24th place 5 years ago, but down from being the second most popular language (after C) 25 years ago.

According to The Great Programming Language ShootOut (recently renamed to The Benchmarks Game), Ada is almost as fast as C (then again, so are Pascal and Fortran), but it's also the most verbose language in the comparison!

Unsurprising, given how much them lazy overpaid government contract moochers hate efficiency...

Also note that there doesn't seem to be a genuinely free implementation of Ada... (Note that LLVM DragonEgg is still based on GPLv3'ed GCC, puke.)

The only thing to like about that language is its name!

--libman

Meant to include link to what Apple did with LLVM and OpenGL: http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html

Its not necessarily about an advantage of either really.. clang/llvm is really more about modularity and focusing on a more flexible toolchain.

As an example, if you want to compile from c-> binary in linux, theres quite a command path depth to it (i.e. multiple processes take place in serial to eventually produce a binary). The problem with gcc is that the code has become messy and its modular approach doesnt really help when it comes to adding a new language or a new target (i.e. F# perhaps, or ARM as a target). It also carries alot of legacy cruft with it that has been there since the dawn of time.

Ultimately when you do want to add a new language or target, you almost end up re-writing the entire gcc stack which is quite painful.

clang/llvm is really about getting rid of that pain with a more modular approach so if you want to add a language or a target, you just focus on your goal not the entire toolchain. As a Plus, its also gotten rid of some of the antique cruft which is at least part of the reason its often faster. IMHO - its faster in some situations, but not all.

None of this really matters much to the end user (except perhaps the speed bit)... What does matter (and what you will care about) is as clang/llvm matures you'll find developers more likely to target clang/llvm for compiler toolchains with new languages or targets.

The other thing you might care about as well is that its better with errors, they are alot clearer and more useful and for that see http://clang.llvm.org/diagnostics.html however, that only extends to clang really.

I don't see anybody addressing this question adequately. Here goes for a start.

1) g++ has simply awful error messages for template code. clang++ has MUCH more helpful error messages. Of not quite so much importance, all clang/clang++ error messages are significantly better than those of gcc/g++. Looks like clang++ has spurred g++ to improve error messages in 4.8 though. They NEEDED to be improved.

2) clang++ 3.1 has significantly better C++11 support than g++ 4.7:
      Rvalue refs for *this
      Alignment support
      Strong compare-exchange
      Bidirectional fences
      Atomics in signal handlers
      Also borrows from C99 one very significant enhancement: C99 designated initializers

References:
clang: Expressive Diagnostics
C++0x/C++11 Support in GCC
C++98 and C++11 Support in Clang

I don't see anybody addressing this question adequately. Here goes for a start.

1) g++ has simply awful error messages for template code. clang++ has MUCH more helpful error messages. Of not quite so much importance, all clang/clang++ error messages are significantly better than those of gcc/g++. Looks like clang++ has spurred g++ to improve error messages in 4.8 though. They NEEDED to be improved.

2) clang++ 3.1 has significantly better C++11 support than g++ 4.7:
      Rvalue refs for *this
      Alignment support
      Strong compare-exchange
      Bidirectional fences
      Atomics in signal handlers
      Also borrows from C99 one very significant enhancement: C99 designated initializers

References:
clang: Expressive Diagnostics
C++0x/C++11 Support in GCC
C++98 and C++11 Support in Clang

Could check this article: http://clang.llvm.org/comparison.html

Apple made the switch a while back in Xcode. The end result was much better debugging and refactoring capabilities.

But there's a difference between making sure your kernel and toolset can compile on multiple platforms and inventing a new platform just so you can say your toolset/kernel can compile on multiple platforms.

Apples tool set doesn't compile on arm. Until the you see a Darwin Arm host build bot, this is just wild speculation.

That's it, I'm switching to LLVM!

That'a a truly unique pattern of reasoning (given that LLVM is written in C++)

OpenCL
Webkit
Bonjour
Clang
libdispatch
....
So wat is the point you are trying to prove ?

vector types:
I don't mean c++ vectors, I mean opencl like vectors. float4, double2, etc... and vectorized versions of the standard math libraries sin, cos, etc... So you can do true cross compiler, cross platform, and cross cpu vector programming.

closures:
In corporate Clang blocks. They are just so useful.

Imagine no GCC

Done

Actually, Apple stopped shipping GCC a long time ago. /usr/bin/gcc is just a compatibility-wrapper on top of LLVM which translates command line options for GCC to the equivalents in LLVM.

Is that "LLVM the project" or "LLVM the code generator and optimizer library"? The latter has no command-line options to translate to. The former includes clang, which is a C/C++/Objective-C front-end that can be combined with the LLVM code generator and optimizer to form a C/C++/Objective-C compiler; that compiler has a set of command-line options that, by and large, are the same as those of GCC. /usr/bin/gcc was, at least in the Lion timeframe, the same as llvm-gcc, which is "a modified version of gcc that compiles C/ObjC programs into native objects, LLVM bitcode or LLVM assembly language, depending upon the options." - GCC front-end, LLVM back-end. Its native command-line options are pretty much the same as those of GCC ("Being derived from the GNU Compiler Collection, llvm-gcc has many of gcc's features and accepts most of gcc's options.").

Perhaps in the latest versions of XCode /usr/bin/gcc runs clang rather than llvm-gcc.

So, no translation - the main C/C++/Objective-C compilers built from the LLVM back end use, by and large, the same command-line options as GCC (why bother making them different just to be different?).

Actually, Apple stopped shipping GCC a long time ago. /usr/bin/gcc is just a compatibility-wrapper on top of LLVM which translates command line options for GCC to the equivalents in LLVM.

Is that "LLVM the project" or "LLVM the code generator and optimizer library"? The latter has no command-line options to translate to. The former includes clang, which is a C/C++/Objective-C front-end that can be combined with the LLVM code generator and optimizer to form a C/C++/Objective-C compiler; that compiler has a set of command-line options that, by and large, are the same as those of GCC. /usr/bin/gcc was, at least in the Lion timeframe, the same as llvm-gcc, which is "a modified version of gcc that compiles C/ObjC programs into native objects, LLVM bitcode or LLVM assembly language, depending upon the options." - GCC front-end, LLVM back-end. Its native command-line options are pretty much the same as those of GCC ("Being derived from the GNU Compiler Collection, llvm-gcc has many of gcc's features and accepts most of gcc's options.").

Perhaps in the latest versions of XCode /usr/bin/gcc runs clang rather than llvm-gcc.

So, no translation - the main C/C++/Objective-C compilers built from the LLVM back end use, by and large, the same command-line options as GCC (why bother making them different just to be different?).

Actually, Apple stopped shipping GCC a long time ago. /usr/bin/gcc is just a compatibility-wrapper on top of LLVM which translates command line options for GCC to the equivalents in LLVM.

Is that "LLVM the project" or "LLVM the code generator and optimizer library"? The latter has no command-line options to translate to. The former includes clang, which is a C/C++/Objective-C front-end that can be combined with the LLVM code generator and optimizer to form a C/C++/Objective-C compiler; that compiler has a set of command-line options that, by and large, are the same as those of GCC. /usr/bin/gcc was, at least in the Lion timeframe, the same as llvm-gcc, which is "a modified version of gcc that compiles C/ObjC programs into native objects, LLVM bitcode or LLVM assembly language, depending upon the options." - GCC front-end, LLVM back-end. Its native command-line options are pretty much the same as those of GCC ("Being derived from the GNU Compiler Collection, llvm-gcc has many of gcc's features and accepts most of gcc's options.").

Perhaps in the latest versions of XCode /usr/bin/gcc runs clang rather than llvm-gcc.

So, no translation - the main C/C++/Objective-C compilers built from the LLVM back end use, by and large, the same command-line options as GCC (why bother making them different just to be different?).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

And much more. I guess unixisc should head to http://llvm.org/ and see how many applications LLVM has. It was used to build compilers way before the Clang project started.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

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

Patched are welcome.

GCC itself.

"The development of a new front-end was started out of a need -- a need for a compiler that allows better diagnostics, better integration with IDEs, a license that is compatible with commercial products, and a nimble compiler that is easy to develop and maintain. All of these were motivations for starting work on a new front-end that could meet these needs."
http://clang.llvm.org/

It's missing a decent static analyzer?

It's not quite as simple as that. The development of Clang is being funded by Apple. They need a BSD license so that they have the freedom to make further modifications down the line (without leaving them open). Yes, I'm a GPL advocate. No, I don't agree with Apple's ideology. But it's the case anyway.

In any case, it doesn't do us any harm to have an underdog in the world of open source C compilers. If you only have one option, then people start treating even the programme's eccentricities as standards. The need for compatibility encourages people to document. Not to mention that the different attitude taken in Clang from the offset means that it may be more suitable for certain applications. This page makes for some interesting reading.

Nope, it uses clang
http://clang.llvm.org/

I like the Singapore theme with beamer: it's clean and minimal. here's an example I created recently. The overall structure is beamer with the Singapore theme, the diagrams are done with TikZ, the PDF annotations with pdfmarginpar and the code listings with the listings package. The really nice thing is that you can compose all of these things, so I have some code listings embedded in TikZ drawings: listings does the syntax highlighting and then TikZ places that box somewhere and draws a background behind it and a border around it. TikZ also works really nicely with beamer's build support. Once you've written the diagram, you can just insert \pause commands and you'll get one page with everything before that and one with everything before and after it (but before the next \pause). This makes it really easy to do diagrams where parts appear as you're talking - you do the final version and then insert the build steps at the end. You can also hide things, but that's usually not ideal because the final version that people download typically won't have the build effects, so people who download the slides will see a mess (see any recent Apple presentation for examples of this same problem in Keynote).

Two links, one of which is paywalled and the other doesn't support your claim - he's just saying that if you've got code that, for example, depends on GCC's buggy interpretation of C++ template expansion then it may not work with clang and so you need gcc installed too.

And I'm not sure what you mean by Apple propaganda. Apple is one of the companies that uses and contributes to LLVM, but others include Adobe, nVidia, Qualcomm, ARM, MIPS International, AMD, Cray, and a load of universities.

It's not just been left in the dust by Intel and MS's – it's also been left in the dust by Apple's (now BSDed) clang. It runs faster, produces faster code, produces better error messages, is more amenable for using parts in other tools, has a brilliant static analysis tool that comes with it, ...

And now gcc too has joined the ranks of "crap compiler" – clang runs fast, produces faster code, produces better error messages, is more modular, is licensed in a more open way, ...

Run off with a young, pretty, thin floosy instead!

Clang has been able to compile modified versions of the kernel for about 18 months. Here is a summary of the work at the here time which describes what worked and what didn't. You can track the remaining issues for compilation here. So while it's not officially supported, clang is able to produce working kernels. This suggests that it is a matter of time, code maturity and will rather than some fundamental problem. Biggest issues appear to relate to some missing register support and 16-bit x86 assembly. Most gcc extensions are actually supported for compatibility reasons but some are not.The FreeBSD kernel and userland can also be built with Clang.

However, take a look at clang. One day, this and much more will be possible.

Indeed this is so. You can also compile Objective-C using clang/llvm . See: http://clang.llvm.org/compatibility.html#objective-c . The clang implementation is at feature parity with the Mac OS X 10.7 version of the language, and based on my limited understanding of some comments I've read in various announcements, supports some additional features as well. Use of those features requires the GNUStep Objective-C runtime (libobjc2), rather than the GCC runtime. A high degree of Cocoa compatibility is available using the GNUStep Base (Foundation) and GNUStep GUI (AppKit) libraries, for numerous Unix platforms as well as Windows. A version of CoreFoundation is also available which wraps GNUStep Base, with a rewrite coming very soon that implements CoreFoundation in plain C. Various other Cocoa and iOS-compatible libs are available in disparate states of implementation. As always, GNUStep could use more developers and more users. Companies wishing to port their MacOS software to other platforms are encouraged to investigate GNUStep; previous porting efforts have positively contributed to the project by discovering and reporting bugs and sometimes by providing direct improvements.

GNUStep was recently used to port the Mac-only racing game CoreBreach to Linux: ( http://corebreach.corecode.at/CoreBreach/About.html ). Other visible examples of Cocoa/Objective-C applications ported to Linux from MacOS include the 'eggPlant' automated testing tool from TestPlant ( http://www.testplant.com/ ), and plenty of previously Mac-only Free/Open-Source software such as Bean.app ( http://1.bp.blogspot.com/_2qH5zqXu7wQ/TRi6sNiNZjI/AAAAAAAAADM/i8RwqzQ6OYE/s1600/bean-gnome-theme.png ).

The parent is correct that you do not need Apple kit to develop in Objective-C. To work with most examples you will find, you will need Cocoa-compatible development libraries and tools, though. Interesting starting points include the Windows Installers, which include all of the components you would need to get started ( http://www.gnustep.org/experience/Windows.html ), or the GNUStep Core packages ( http://www.gnustep.org/resources/downloads.php ) for other platforms. The Étoilé Project http://etoileos.com/ is also interesting. Those of you in Europe who are interested and intend on attending FOSDEM should stop by and visit the talks and devroom sponsored by these projects.

ARC is not garbage collection by the normal definition. There is no runtime component doing the clean up. The compiler inserts retain and release messages at the appropriate points in the code based on convention and static analysis.

One of the big implications is that cycles are not handled automatically as they would be in a (well-implemented) GC.

It's actually pretty neat.

(they've since replaced it with closed proprietary shit)

Let's not lie.

As noted in the release notes, FreeBSD 9.0 includes Clang/LLVM, the goal is to be rid of all GPL dependencies by version 10.0. At the 2011 LLVM Developers' meeting, Brooks Davis covered the effort in bringing in LLVM for 9.0 and the work remaining for 10.0 to replace GCC. The move was originally intended for 9.0, but there wasn't enough time to get it all done, particularly due to the thousands of pieces of software in the ports tree that still require work. GPLv3 is cited as the catalyst for all this, for preventing cooperation between free and proprietary software sectors.

As noted in the release notes, FreeBSD 9.0 includes Clang/LLVM, the goal is to be rid of all GPL dependencies by version 10.0. At the 2011 LLVM Developers' meeting, Brooks Davis covered the effort in bringing in LLVM for 9.0 and the work remaining for 10.0 to replace GCC. The move was originally intended for 9.0, but there wasn't enough time to get it all done, particularly due to the thousands of pieces of software in the ports tree that still require work. GPLv3 is cited as the catalyst for all this, for preventing cooperation between free and proprietary software sectors.

Don't forget LLVM, which is probably more important than the rest of those put together.

It's set to potentially replace the back-end of GCC, Mono, GHC (Haskell), and probably a stack of other things. There's going to be a point in the near future where something like over half of the popular programming languages out there in the non-Windows world will be using an LLVM compiler back-end.

jobs: you will pry my source code out of my cold dead hand.
god: ok.

satan: both of you forgot about darwin and the stuff other than alac at mac os forge and stuff such as clang and lldb at llvm.org....

Which is dumb when you think about it. If your application doesn't require all the latest features and a lot of CPU/GPU power, why cut yourself from potential sales? There's a lot of iOS3 devices out there.

As an example, ARC requires iOS 4.
And since ARC simplifies memory management considerably, there is a strong incentive to drop support for iOS 3.

maybe they should switch to clang.

You can, 10 years ago.

Can't wait to get my hands on a FOSS clone of it.

It's called LLVM. As usual, Microsoft is trailing everyone else, including FOSS, and claiming it as their own; albeit in traditional embrace and extend fashion, with some unique tweaks.

What sets this apart from LLVM and clang except for the languages it supports?

What sets this apart from LLVM and clang except for the languages it supports?