Hi, I'm writing to both lists as I'm not sure what the cause of this issue is. I use code like this to compile C source into LLVM IR as suggested on the Clang mailing list previously. class CompileBitcodeAction : public clang::EmitLLVMOnlyAction { protected: Module*& dstModule; public: inline CompileBitcodeAction(Module*& dstModule, LLVMContext* const context = NULL) : clang::EmitLLVMOnlyAction(context), dstModule(dstModule) {} protected: virtual inline void EndSourceFileAction() { clang::EmitLLVMOnlyAction::EndSourceFileAction(); dstModule = takeModule(); } }; Module* module = NULL; ToolInvocation tool(cmdLine, new CompileBitcodeAction(module, context), fileManager); The command line is set up for C (-x c). I use different ToolInvocation instances and LLVM contexts to compile multiple modules sequentially. This works fine with LLVM/CLANG 3.1. However, since 3.2 I got the following problem. Two C modules containing a definition of some variable x: mod1.c: short x = 1; mod2.c: short x; produces the bitcode: mod1.c: @x = global i16 1, align 2 mod2.c: @x = global i16 0, align 2 which seems to be wrong as the second definition should have common linkage. Interestingly, it works if I (a) use stand-alone clang (for reference), (b) compile only one module, or (c) reverse the order of the modules. Does anybody know what's wrong here? How can the first compilation affect the second one like this? Thanks & ciao, Mario