Compiler differences - xcode

I'm an iOS developer, I don't know how compilers work and I want to ask what is the difference between the LLVM GCC 4.2, the Xcode 4 default compiler and the GCC 4.2 compiler, the Xcode 3 default compiler.

Here is my understanding
GCC 4.2 is the (mostly) stock standard open source GNU C compiler that works with C, C++ and Objective-C. Its pretty much the standard compiler used in all open source, and its tried and true tested. But because its old technology, its just a compiler, it has no hooks for other uses. And its quite generic, being CPU and platform agnostic.
LLVM is the next generation of compilation software. It's syntax and semantically aware, compiling to a byte code and then to native, and it provides hooks so IDE's and other tools can use its knowledge. It's this awareness that allows Apple to improve auto-completion, implement fixit and do the build and analyze stuff in Xcode 4. LLVM is the future for Apple, and the future for GCC. LLVM also produces allegedly tighter code, as its optimizations are smarter (not sure about this). LLVM also allows for more dynamic language bindings at some point.
LLVM GCC is the half-way mark, the syntax and semantic preprocessing of LLVM with the old GCC back end compiler.
The way I use them
I use LLVM during development, as it keeps me warned of any and all issues. Really helped when I ran it the first time on legacy code and found some issues.
I use GCC to produce the final executable for iOS 3.1.3 apps, and LLVM for all the iOS 4.0 / Mac 10.6 apps.

Related

Clang or GCC compiler for c++ 11 compatibility programming on Windows?

I was wondering which compiler is better to use on Windows OS (8.1) in temrs of compatibility to c++11's (and later 14) functions, liberies and features (like lambdas) and is also comfortable to use (less bugs).
I am a university student hence I'm not looking at the subject product-wise (even though I do like to code a bit more than just projects for my studies).
I am currently using eclipse luna IDE if it matters.
Notice that compiler != IDE.
VC++ is one of the most populars on Windows and depending on its version it has a good support for C++11 features. Check the list on the msdn blog to find out if there's everything you need.
Gcc is also ported to Windows and you can install MinGW to use it (4.8.1.4 at the moment of writing this). It is pretty complete on C++11.
Clang is also available for the Windows platform and it is also complete on C++11 support (plus it has good diagnostic messages), but notice that you will have to use another linker since clang doesn't ship with one (although there is an ongoing effort to write it: http://lld.llvm.org/)
All the compilers I cited above are pretty stable but, based on my experience, if you're looking for latest and greatest C++11/14/17 features, you might just want to go for gcc or clang (VC++ is slower in adding support for newest features and the compiler is undergoing a huge update to modernize). Just keep in mind that these are compilers and not just IDEs, an IDE is a front-end supporting program that uses a compiler undercover to compile files.
To set up a C++11 compiler, I suggest installing MSYS2, it has a package manager (pacman) that can install fresh versions of GCC, GDB, Clang and many libraries like SDL, Lua etc. Very easy to use too.
As far as GCC vs CLang goes - I really tried hard to make CLang work (which is presumably faster and more friendly than GCC - produces better warnings, etc.), but failed. Issues were that CLang (which comes with MSYS2) is hard-coded to use GCC linker which produces some strange linker errors when using libstdc++ (std implementation from GCC). libc++ (a new implementation designed to work with CLang) didn't worked for me on Windows either.
So you either try build CLang from sources and hope that some configuration will work with C++11 library, OR just stick with GCC which works just fine out of the box.
As IDE, I suggest to take a look at CLion. It is very comfortable (infinitely more user-friendly and intuitive than Visual Studio, IMO). Just install it and point it to the mingw64 (or mingw32) folder of MSYS2, it will auto-detect everything for you.
It only works with CMake projects though.

how to use OpenMP library in xcode 5.1?

I want to use openMP library in my project but it seems as if there is no option for openMP in xcode 5.1. if someone knows then please help me
There is clang with OpenMP 3.1/4.0 support (though not official). You can take it here http://clang-omp.github.io/
OpenMP is not a library but a language extension to C, C++ and Fortran. It requires support built into the compiler. Xcode uses compilers based on the LLVM infrastructure. It used to provide two different compiler front-ends - Clang and GCC. Of those two, the former does not have support for OpenMP (yet). The GCC front-end provided some support for old OpenMP features but is no longer part of Xcode. It used to be based on a very old GCC version (4.2.1) and not actively updated since Apple started throwing all their resources into improving Clang.
In other words - no OpenMP support in Xcode 5.1. You can build your own modern (but non-LLVM) GCC from source and use it on the command line, but it's hard to integrate it with Xcode.

Compiling for Cortex M3 bare metal

Is there a guide somewhere that describes how to get LLVM to emit a binary for Cortex-M3 that I can massage into running bare metal? I've spent considerable time playing with LLVM on Windows and Ubuntu to no avail. I can get ARM-like assembly out. I can get bit code out, but what I really need is ELF, DWARF, Hobbit, Gandalf or any other Lord of the Rings critter that has a file format specification. Any and all help appreciated! I'm compiling LLVM 3.4 with CLANG on Ubuntu, Windows and/or OS X.
I created a firmware framework - PolyMCU https://github.com/labapart/polymcu - that is based on CMake that support GCC and LLVM. Because it is based on CMake you can build your firmware on Linux/Windows/MacOS.
It also uses Newlib and supports Baremetal/CMSIS RTOS (RTX)/FreeRTOS.
The benefit of using PolyMCU is this framework does not add any software layer on top of the libc and the MCU vendor's SDKs.
Another benefit is you can easily switch toolchains. I used this feature to get more feedback on my code by testing it with many compilers.
I also wrote a blog where I compared GCC and LLVM build size on ARM Cortex-M: http://labapart.com/blogs/3-the-importance-of-the-toolchain-version-in-embedded-space Interesting results, Clang generated code is not much bigger than GCC on Cortex-M...
The best guide that I know of is here: http://wiki.osdev.org/LLVM_Cross-Compiler. It's mostly about building an LLVM cross-compiler, but it does show a "Usage" section. However, that section specifically shows an example for a Cortex-A processor, but you should be able to get the general idea.
I have created an simple clang bare metal Cortex-M3 "hello world" program, but I don't have it in front of me. IIRC, the only options I needed were -march=thumb -mcpu=cortex-m3 as long as the LLVM compiler backend was built with the ARM thumb backend support (Again, see http://wiki.osdev.org/LLVM_Cross-Compiler). I did, however, need to link with arm-none-eabi-ld from the GCC toolchain here (http://launchpad.net/gcc-arm-embedded), and I believe that is how you can get your ELF binary.
I've since moved on to the D programming language, and I have a simple example using LDC (The LLVM D compiler) here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22)
So, I believe compiling bare metal ARM Cortex-M3 software with LLVM can be done, but it seems not many people have tried.
It is possible to use clang++ pulled from http://llvm.org/builds with https://launchpad.net/gcc-arm-embedded as a base, at least for the compile step.
Required extra arguments are the include paths hardcoded into gcc and certain arm-none-eabi defaults:
--target=arm-none-eabi -fshort-enums -isystem "../arm-none-eabi/include/c++/5.2.1" [-isystem ...]

xcode - Using Apple LLVM compiler 3.0 to compile for PowerPC CPUs

I'm working on someone else's application and so far he has built it in XCode 4. XCode 4 has eliminated support for PowerPC architectures, but we would still like to support PowerPCs for some of our users.
I have followed this tutorial on SO, informing me how to restore ppc compatibility to XCode 4, however, this is for the GCC (4.2) compiler which throws a lot of warnings and some errors when compiling the code. The code is optimized around Apple's LLVM 3.0.
My questions:
Is it possible to use Apple LLVM
compiler 3.0 for Power PC deployment?
How would one go about doing this?
What settings variables do I need to
set in order to get PPC compatibility
when compiling?
Thank you!
Pretty much no, it's not possible. Apple LLVM 3.0 hasn't been tested or verified to work at all with PowerPC.

Code Sourcery GCC vs Vanilla GCC Compiler, what is the difference?

I've found a company that provides GCC based toolchains for ARM, MIPS but I don't know in what are they different from the vanilla GCC, of course, they bring other software pieces such as Eclipse, but when looking only at GCC and Binutils, are they different or just the same?
One big difference between a pre-compiled toolchain (like those provided by Code Sourcery, MontaVista, Wind River, etc) and one built from source is convenience. Building a toolchain from scratch, especially for cross-compiling purposes, is tedious and can be a complete pain. Also, the newest versions of glibc (or uClibc), gcc, and binutils aren’t always compatible as they're developed independently. There are open source tools to make this process easier (like crosstool-NG), but having a proven toolchain that’s been optimized for a certain platform can save a lot of time and headaches. This is especially true at the beginning of a new project. It also helps to have technical support when things go screwy. Of course…you have to pay for it most of the time.
That being said, compiling your own toolchain will most likely save you money and can allow more flexibility down the road. MontaVista, as far as I know, doesn’t include support for older platforms in their newest toolchain releases. For example, if you bought MontaVista Pro 4.X and it included a toolchain with gcc 3.3.X, that’s the toolchain you’re most likely going to be stuck with for the life of your project. Upgrading to a toolchain with gcc 4.X most likely wouldn’t be an option.
Hope that helps.

Resources