llvm

How I can generate a working executable with the tools provided with Llvm/Clang ( version 3.3 (trunk 168461) ) ? I have compiled an object with clang++ -c [...] and i would like to try to link this object to 1 specific library and see if this can generate a working executable. I have noticed that from the 3.1 release llvm-ld it's been removed and llvm-link doesn't look like it has inherited all the options from llvm-ld , although it's marked as the alternative to llvm-ld on the official docs, so i just don't get how I'm supposed to link this object. I don't want to use ld from the GNU/GCC

I write a simple llvm plugin pass that requires opt to load xxx.so file and run a ModulePass. The strange thing is that when I use deb package opt (e.g., from apt-get , let's call it opt-3.7 ), the plugin works fine (the drawback is that it is a Release build); however when I use the opt I build myself (simplify call it opt ), it frequently complains: Error opening 'xxx.so': xxx.so: undefined symbol: _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE using c++filt I know that opt cannot find llvm::FunctionPass::createPrinterPass

Recently I upgraded my project settings in Xcode 4.3 and now I use the latest llvm debugger: lldb However (sometimes) I have the impression the debugger is not giving me the correct info? Could this be possible? For example, The debugger says _documentsItem is nil (both in in the console and when mouse-over-ing the ivar). But I know it's NOT , that is why I can see it (an UIBarButtonItem) and more important that is why the app stopped at the shown breakpoint) if (_documentsItem) { ... In fact most of my properties return nil too :( Is there a way I make sure the debugger is doing fine? I've

So I'm trying to build a toy compiler using LLVM and I'd like to use CMake as my build system. I tried using the sample CMakeLists.txt from LLVM's website, but I encounter the following error when running cmake : CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): include could not find load file: /usr/share/llvm/cmake/LLVMExports.cmake Call Stack (most recent call first): CMakeLists.txt:4 (find_package) CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:181 (include): include could not find load file: /usr/share/llvm/cmake/LLVM-Config.cmake Call Stack (most recent

I've run into this issue in the past: LLVM defines __GNUC__ , but it can't consume a program GCC can. I'm experiencing it again on Windows: LLVM defines _MSC_VER , but it can't consume the same program VC++ can. The aggravating thing (for me) is we have specialized code paths for LLVM Clang and Apple Clang (different defines due to different version schemes), and we have to fight with the tool to get it to use them. How do we tell Clang to stop pretending to be other compilers? Is there a switch or option to do it? The Clang docs discuss the unwanted MS behavior , but they don't say how to

New Xcode 4.4 is out and it should support literals like @42 @"String" @23.0L @{ @"key" : obj } and @[obj1, obj2] and it should also support @YES and @NO , which isn't working when targeting latest iOS 5 (and prior). After compiling it show the error message: Unexpected type name 'BOOL': expected expression I know you can fix it by typing @(YES) and @(NO) . But I want to know the reason why it isn't working as expected. The reason is Apple forgot the parentheses here: #define YES (BOOL)1 This will be fixed in iOS 6 SDK: #define YES ((BOOL)1) In the meantime you must type @(YES) . James Webster

I'm using (Apple) LLVM 4.1 within Xcode 4.5 (but I saw the same thing in an earlier beta). I have it targeting C++11 and am using libc++ (the new, C++11 enabled, LLVM version of the std library). In a debug build, if I try to step over code that calls into a std library function (e.g. a std::vector constructor) the debugger stops in the std lib implementation and if I try to step out it steps even deeper! It can take several (sometimes 10 or more) step-outs before I get back to my own code (and I never wanted to step in in this first place). There always seems to be a _LIBCPP_DEBUG macro in

Are the three main compiler flavors supported by Xcode (gcc 4.0, 4.2, and llvm) binary-compatible with one another? What kind of gotchas and corner cases should I be aware of when bringing a multi-library project up to speed with the most recent Xcode tools? Clang is ABI-compatible with code generated by gcc. Clang also includes experimental support for some newer Objective-C ABIs, but compiling for the newer ABI requires flags, and generated code can be mixed with GCC-generated code anyway. A minor gotcha is that if you want to compile PowerPC code that will run on a G3, you must use GCC 4.0.