LLVM-GCC on OS X Lion

I confused about GCC version brought by XCode 4.2 on OS X Lion, so I surfing and landing on several sites to find out what is this llvm version.

Here some result.

Llvm stand for low level virtual machine



The LLVM Project (llvm.org) is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them.

The llvm-gcc command is the LLVM C front end. It is a modified version of gcc that compiles C/ObjC programs into native objects, LLVM bitcode or LLVM assembly language, depending upon the options.

By default, llvm-gcc compiles to native objects just like GCC does. If the -emit-llvm and -c options are given then it will generate LLVM bitcode files instead. If -emit-llvm and -S are given, then it will generate LLVM assembly.

Being derived from the GNU Compiler Collection, llvm-gcc has many of gcc's features and accepts most of gcc's options. It handles a number of gcc's extensions to the C programming language. See the gcc documentation for details.

Clang vs GCC (GNU Compiler Collection)

Clang ( /ˈklæŋ/)[2] is a compiler front end for the C, C++, Objective-C, and Objective-C++ programming languages. It uses the Low Level Virtual Machine (LLVM) as its back end, and Clang has been part of LLVM releases since LLVM 2.6.

Its goal is to offer a replacement to the GNU Compiler Collection (GCC). Development is sponsored by Apple. Clang is available under a free software license.

The Clang project includes the Clang front end and the Clang static analyzer among others.[3]

Pro's of GCC vs clang:

• GCC supports languages that clang does not aim to, such as Java, Ada, FORTRAN, etc.
• GCC has a few C++'11 features that Clang does not yet support.
• GCC supports more targets than LLVM.
• GCC is popular and widely adopted.
• GCC does not require a C++ compiler to build it.

Pro's of clang vs GCC:

• The Clang ASTs and design are intended to be easily understandable by anyone who is familiar with the languages involved and who has a basic understanding of how a compiler works. GCC has a very old codebase which presents a steep learning curve to new developers.
• Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.
• Various GCC design decisions make it very difficult to reuse: its build system is difficult to modify, you can't link multiple targets into one binary, you can't link multiple front-ends into one binary, it uses a custom garbage collector, uses global variables extensively, is not reentrant or multi-threadable, etc. Clang has none of these problems.
• For every token, clang tracks information about where it was written and where it was ultimately expanded into if it was involved in a macro. GCC does not track information about macro instantiations when parsing source code. This makes it very difficult for source rewriting tools (e.g. for refactoring) to work in the presence of (even simple) macros.
• Clang does not implicitly simplify code as it parses it like GCC does. Doing so causes many problems for source analysis tools: as one simple example, if you write "x-x" in your source code, the GCC AST will contain "0", with no mention of 'x'. This is extremely bad for a refactoring tool that wants to rename 'x'.
• Clang can serialize its AST out to disk and read it back into another program, which is useful for whole program analysis. GCC does not have this. GCC's PCH mechanism (which is just a dump of the compiler memory image) is related, but is architecturally only able to read the dump back into the exact same executable as the one that produced it (it is not a structured format).
• Clang is much faster and uses far less memory than GCC.
• Clang aims to provide extremely clear and concise diagnostics (error and warning messages), and includes support for expressive diagnostics. GCC's warnings are sometimes acceptable, but are often confusing and it does not support expressive diagnostics. Clang also preserves typedefs in diagnostics consistently, showing macro expansions and many other features.
• GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be used by projects that do not themselves want to be GPL.
• Clang inherits a number of features from its use of LLVM as a backend, including support for a bytecode representation for intermediate code, pluggable optimizers, link-time optimization support, Just-In-Time compilation, ability to link in multiple code generators, etc.
• Clang's support for C++ is more compliant than GCC's in many ways (e.g. conformant two phase name lookup).

From forum (http://www.cocos2d-iphone.org/forum/topic/7923)
"Have you experienced any incompatibility between LLVM compiler and GCC compiler ?


I found one strange issue:
If you compile ParticleTests with GCC and if you try sub-test "issue 872", it works as expected: a particle system will emit particles.
But if you compile it with LLVM 1.5, you won't see any particle at all. I'm not sure what's the problem, but I'll investigate it a bit further.


I can only reproduce this bug on the simulator. It seems that this bug can't be reproduced on the devices.


I tested it both in Release & Debug mode using Xcode 3.2.3"
............

"A developer at Apple (guy working on LLVM) highly suggested moving away from GCC immediately. He says Apple is no longer fixing bugs in GCC, and in XCode 4 GCC-LLVM will be the default option.


I've noticed sometimes LLVM will not compile against really old libraries compiled with GCC (gives errors about built in runtime functions not found). I can fix that by using GCC-LLVM (gcc parser, LLVM code generator).


A few days ago I noticed a bug in my code that only showed up when using LLVM (but not GCC). I tracked it down to a non initialized local variable that was being read from, and GCC would always initialize to zero (even with O3 optimizations). Since the variable value should be undefined, LLVM was giving the correct behavior of using whatever was in that memory already (even though it's clearly not the desired result). I'd speculate something similar is going on with ParticleTests.


I did a quick test, and compiling Cocos2D with GCC-LLVM works correctly with issue 872."