For those that follow game development, John Carmack had this to say at QuakeCon 2012:

"But, one of my pushes on the greater use of static analysis and verification technologies, is I pretty strongly suspect that the Clang LLVM sort of ecosystem that's living on OS X is going to be, I hope, fertile ground for a whole lot of analysis tools and we'll wind up benefiting by moving more of our platform continuously onto OS X just for that ability to take advantage of additional tools there." [1]

[1] https://www.youtube.com/watch?v=wt-iVFxgFWk#t=45m4s

I love the community of languages that have adopted LLVM as a back-end: http://llvm.org/docs/ReleaseNotes.html#external-open-source-...

Pure, FAUST, Julia, Clay are all very promising and I didn't know about Open Shading Language or Portable OpenCL.

[1] http://code.google.com/p/pure-lang/

[2] http://faust.grame.fr/

[3] http://julialang.org/

[4] http://claylabs.com/clay/

[5] https://github.com/imageworks/OpenShadingLanguage/

[6] http://pocl.sourceforge.net/

You missed my favorite LLVM-based project, ispc[1].

In a nutshell, it brings nVidia's SPMD programming model to normal SIMD-capable processors. Any CUDA code out there is almost trivial to convert.

[1] http://ispc.github.com/

Haskell and Rust are also worthy of mention here.

Does GHC use the LLVM backend by default or do you have to manually enable that?

No, the default backend is the native code generator. You need to use the -fllvm flag to enable the LLVM backend.

http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/code-...

"[The LLVM backend] is an alternative backend that uses the LLVM compiler to produce executable code. It generally produces code as with performance as good as the native code generator but for some cases can produce much faster code. This is especially true for numeric, array heavy code using packages like vector. The penalty is a significant increase in compilation times."

Admittedly, I don't write much C/C++ anymore, but for a recent project, I need to use C. I decided to try clang instead of gcc. When clang showed me exactly what the source (via colors and indicators) of my compilation error I immediately knew that clang is the way forward.

Use this link instead: http://llvm.org/releases/3.2/docs/ReleaseNotes.html

The original link points to some draft version with lots of placeholder text throughout.

Another great LLVM tool that I don't see much press about is scan-build. It does static analysis and lets you navigate the results in your web browser. I believe Xcode builds this in but it's nice for anyone not using an IDE.

http://clang-analyzer.llvm.org/scan-build.html

Doxygen users will be glad to know that Clang now can syntax check your Doxygen comments.

-Wdocumentation, FYI

Anyone using LLVM/Clang on Windows? If so did you have to do anything special to get it to work? I have not really looked into it much myself as the last time I did Windows was basically a no go. Any advice would be great thanks!

I've toyed with it a bit. The three biggest problems are probably the inability to link with libs that were compiled with MSVC (they are working on being able to make and consume libs that are MSVC compatible, but it isn't there yet), problems parsing Windows based source code (i.e. things knowingly or unknowingly relying on MSVC only extensions), and problems with some of the MS STL headers, particularly in 2012 type_traits and some non-conformant macro expansion behavior in MSVC that Clang hasn't emulated (so parsing headers using macros that rely on said expansion behavior fails). I have a patch proposed for the type_traits issues and am waiting for some feedback from Chandler on the patch. It has already been reviewed/signed off on by two others, so hopefully acceptance is close. I believe there are patches for the macro issue the floating around, but they haven't been committed since when one was it broke building gtest :(

I'd love it if Clang could accept decently-compliant C++11 source and emit something that MSVC could compile. Like the old Comeau C++ did.

We use LLVM on Windows in Rust. It works OK in general, but the biggest issue is that C++ zero-cost exceptions don't work. We'll have to implement our own workarounds for this at some point.

Are you saying that Windows cannot support zero-cost exceptions? Do you have documentation on why that is?

It can, and GCC and MSVC support it (via different mechanisms -- GCC uses DWARF and MSVC uses its own format), but it isn't implemented in LLVM.

It would be a tremendous gain for the project if someone zipped up an all-in-one, ready to use package for Windows consisting of Clang and working standard libraries for C and C++. It doesnt (yet) need to be the new libc++ STL, a copy of the GCC libstdc++ libs would be enough.

It appears someone has done some work on it. See http://sourceforge.net/projects/mingw-w64/files/Toolchains%2...

I gave it a very quick look however got missing DLL messages (pthreadGC2) when trying to compile. I don't have the time to look into it today, hopefully over the Christmas break I will be able to get it working. If I do I will look at how sensible it is to maintain a similar Windows build. A standard Windows build available as an archive or an installer would be great.

EDIT: The error messages look like they may be related to Cygwin although I could be totally wrong on that, it is just the readme mentions Cygwin but nothing else :)

The solution is to install a very specific build of MinGW. See http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056..., where the recommended MinGW installation is "mingw-get-inst-20120426.exe". Then you must remove any other C compilers from your path and include this MinGW and llvm. On my Windows 7 x64 system I have three versions of Visual Studio and 2 other installations of MinGW, so I was careful to remove them all from my path. I created a pathclang.bat containing the following

    set PATH=C:\Windows\system32;c:\MinGW32\bin;c:\llvm\bin
    set CPATH=C:\MinGW32\include

and got clang 3.2 to work in 32-bit mode:

    pathclang.bat
    clang -m32 -o hello.exe hello.c
    hello.exe

Alas, it appears that 64-bit mode is currently unsupported on Windows.

I used Clang 3.1 to compile some small C programs on Windows, and the only problem I ran into was Clang defaulting the search paths based on the compiler used to build Clang itself. So, kind of goofy that Clang usage depends on whether you used MinGW or MSVC to build it (why isn't it compiling itself, anyway?), but easy enough to work around by adding the search paths on the command line.

Clang works great under Cygwin.

Why would one prefer to use LLVM over GCC?

As somebody who is learning C++ and decided to go with clang, the error reporting is absolutely phenomenal. It tells me not only what line errors are on but also makes suggestions as to how to fix it. I don't ever recall GCC having very helpful error messages.

Agree. Clang vs. GCC is like PostgreSQL vs. MySQL (regarding usefulness of error messages).

GCC has nested functions, which most GCC users hate. Clang has blocks, which are at least widely used on OS X at least and proposed for standardization. I'm not sure this is a point in GCC's favor.

As an Objective-C (iOS) developer, I really love blocks. I thought the syntax was kind of weird when starting to learn it, but it's grown on me. I really hope ObjC blocks will become part of the C standard someday. If I remember people have proposed C++ lambdas to become part of the C standard as well. It will be interesting to see which one (if any) will win in a standardising process.

More info on ObjC blocks vs C++ lambdas in this blog posting: http://www.mikeash.com/pyblog/friday-qa-2011-06-03-objective...

Is that C language features or compiler-specific extensions? Arguably, sticking to the standard is actually the better alternative here in terms of portability.

You're right - it's a compiler extension to a language (apparently) called "GNU C"[1]: http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

Seems like a very nice feature though.

[1]: First time I've heard this term. I'm not sure how I feel about it.

You can usually use "-std=c99" to ban features of concern.

Clang has blocks, which, while different, are at least an arguably superior replacement for gcc's nested functions.

LLVM has a BSD-license. This might be a big deal for some people from a philosophical perspective, but at a more practical level it's great when you need to embed a compiler in your product.

What kind of products allow users to compile and run custom C code, but would feel constrained by the GPL? Any examples (OSX excluded)?

It has nothing to do with "custom C code". Any tool with a custom language (or equivalent) that wants a runtime JIT for the language and code compilable to LLVM IR would need to link in the compiler libs to do that. Custom DSLs are everywhere.

For example, OpenShadingLanguage compiles shaders on the fly as part of a physically-based renderer, and then JITs them at runtime with LLVM. Linked in are the LLVM libs and a bunch of C code that is converted to LLVM IR and accessed by the shaders. The whole lot is linked and JITd together, enabling interprocedural analysis, inlining and a bunch of other compiler optimizations (e.g. constant folding). The resulting shaders are about 25% faster than their previous, hand-coded C shaders.

IOW, lots of products benefit from having a compiler toolchain at runtime they can link with their program. GPL license or not, GCC isn't made to do that.

Suppose you're writing an IDE, and you want to use the clang code to do the heavy lifting of making your editor aware of your program's AST, so that you can easily colorize it, provide in-line warnings & errors, and offer fix-it suggestions.

XCode. GCC is now under GPLv3. I've got a feeling the patent issues in v3 give Apple lawyers a serious rash.

Also with it being under BSD, they can write their own closed source extensions or reuse portions of their code in their own projects.

I'm working on an Apache-licensed product that uses some of it's libraries for code generation.

A few months ago there was a discussion about the problems with the licenses in the Racket Users mailing list:

(first mail) http://lists.racket-lang.org/users/archive/2012-April/051303...

(most relevant mail) http://lists.racket-lang.org/users/archive/2012-April/051319...

They use the LGPL license. The idea is that you can make closed source programs that link to the Racket system as a library, but you must provide a version that is linkable to newer versions of Racket. But in Racket the macro expansions are a fundamental part so the more strict interpretation means almost that you must provide the original source code in plain text.

I don't know enough about licenses, perhaps this is only FUD. And my impression is that the intensions of the Racket creators is that closed source programs in Racket are allowed, but this looks like a gray area.

And the GPL license is more restrictive, but C/C++ has many less macros/templates than Racket.

Cloudera Impala uses LLVM to generate code optimized for the specific query it is running (basically compiling away all the generalness around how large records are, etc). Some kind of native code generation is apparently standard practice in high-performance query engines that are written in languages that don't have a JIT.

Why would it have to be "C code"? LLVM can compile any kind of code with the appropriate front-end. For example, Apple uses it in their OpenGL pipeline, in the (previously Apple sponsored) MacRuby, etc.

Because both LLVM and Clang are librarified from the off, so you can hook them into your own code and use as much or as little of them as you want. You can insert your own passes, make your own drivers, add your own analyses to the static analyzer (http://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf). Or use it to get information to show in an IDE.

It looks like the Clang binaries for 32-bit Ubuntu try to produce 64-bit executables by default:

    # clang -v
    clang version 3.2 (tags/RELEASE_32/final)
    Target: x86_64-unknown-linux-gnu
    Thread model: posix
    # clang hello_world.c
    /usr/include/features.h:324:10: fatal error: 'bits/predefs.h' file not found
    # clang -m32 hello_world.c  # (No error)
    

That's not right, surely?

This is what bit me when compiling g++ on Ubuntu: http://wiki.debian.org/Multiarch

There seemed to be some special magic in the gcc build for Debian-derived distros. It wasn't all controllable with command-line options.

You and Clang may be encountering similar fun.

Sure you didn't download the 64-bit binaries? The 32-bit ones look fine to me.

If you see that on 32-bit ones, file a bug.

This has now been fixed.

The highlight of this release for me: built-in support for the ObjFW Objective-C runtime.

https://webkeks.org/blog/?5f

So an Apple engineer spent time adding support for more 'liberal', non-Apple-based Objective-C runtimes? Wow!

That seems unusual of Apple, but very cool.

EDIT - Looking at the clang source, it looks like GNUstep and and ObjFW (with the exception of old GCC) are the only alternative Objective-C runtimes currently supported by clang: http://clang.llvm.org/doxygen/ObjCRuntime_8h_source.html

Unusual? It'd seem beneficial to Apple in several ways, in that they have multiple ABIs (see the code there!), and in that it keeps other Obj-C users interested in Clang (which means more outside work on the Obj-C frontend).

What other alternative runtimes even exist?

Welp, now I had better go update jllvm to 3.2.

Are they?

Read the actual, complete release notes here:

LLVM, http://llvm.org/releases/3.2/docs/ReleaseNotes.html

Clang: http://llvm.org/releases/3.2/docs/ClangReleaseNotes.html

The project has recently moved to Sphinx, and the transition was only completed after branching for 3.2. It looks like the release notes have gotten out of sync and need to be merged, which is a little more work than usual. The link from the homepage points to docs that are always generated from trunk, so it only has old, incomplete notes.

Yes.

http://llvm.org/releases/download.html#3.2

It went largely unnoticed, but one of the biggest changes of the November Android NDK release was the addition of LLVM/clang to the toolchain. This was primarily added to reduce issues when cross-compiling iOS apps to Android.

unfortunately it ships with older 3.1 version and not 3.2 so for porting it's not the greatest. You can use clang without google's changes just fine though (just have to get the PIC and pie flags right). A few bugs fixed with C++ on android in google's version but nothing major. Or better yet, you can wait until the Apportable SDK is publicly released so your objective-c apps can run on Android. :-)