similar to: [LLVMdev] CMake does not work with LLVM anymore?

Reza Sheykhi <hajishey at msu.edu> writes: > I got the following answers: > > which perl > /usr/bin/perl > > which llvm-config > /usr/local/bin/llvm-config > > which llvm-as > /usr/local/bin/llvm-as > > /usr/bin/llvm-confing --version > bash: /usr/bin/llvm-confing: No such file or directory Uh, there is a typo on the command above, it should be

I got the following answers: which perl /usr/bin/perl which llvm-config /usr/local/bin/llvm-config which llvm-as /usr/local/bin/llvm-as /usr/bin/llvm-confing --version bash: /usr/bin/llvm-confing: No such file or directory /usr/local/bin/llvm-config --version 2.8 Quoting Óscar Fuentes <ofv at wanadoo.es>: > Reza Sheykhi <hajishey at msu.edu> writes: > >> Thank you

Hello, I downloaded LLVM 2.6 and was attempting to compile it with TDM-GCC 4.4.1-tdm2-sjlj + cmake 2.6.4 and this happened: =============Console=================== C:\projects\game-editor\LLVM\build-root>mingw32-make [ 2%] Built target LLVMSystem [ 5%] Built target LLVMSupport [ 7%] Built target tblgen [ 7%] Built target intrinsics_gen [ 10%] Built target LLVMCore [ 12%] Built target

Anyone run into this before? I'm trying to get a Windows native build using Visual Studio of LLVM, Clang, and LLD 4.0.0. So far LLVM built successfully, but I'm getting these cryptic error messages when building Clang: Microsoft (R) Build Engine version 15.1.1012.6693 Copyright (C) Microsoft Corporation. All rights reserved. ClangDiagnosticsEmitter.cpp c:\program files

OK, it's not that bad - it's even better than before :) The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should build on all Win32 variants), extending the copy/paste of winbase.h to this works fine: #if defined(__MINGW32__) ||

On Tue, Nov 8, 2011 at 8:02 AM, Don Williamson <don.williamson at yahoo.com> wrote: > > > OK, it's not that bad - it's even better than before :) > > The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. > > Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should

I am trying to figure out how to free up some memory that seems to be lost when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>()

Hi Vincent, This is an LLVM issue, rather than a clang issue, so llvmdev is the appropriate mailing list for this report. Your fix looks semantically valid, but it would be cleaner to only create and destroy the pthread_rwlockattr_t if it is actually needed, rather than creating it, initialising it, not using it, and then destroying it on mingw (and, as the code currently stands, *BSD). The

I successfully built llvm using msys/mingw, but I am getting the following error when I try to build llvm-gcc using $ ../llvm-gcc4.2-2.6.source/configure --prefix=/c/Temp/msys-llvm-gcc --program- prefix=llvm- --enable-llvm=/c/Temp/msys-llvm --enable-languages=c,c++ --disable -shared $make -------------------------------------------------- gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings

Hi, I'm confused by the comment and the source code of lib/Support/Mutex.cpp and lib/Support/RWMutex.cpp. In these files there are: // This variable is useful for situations where the pthread library has been // compiled with weak linkage for its interface symbols. This allows the // threading support to be turned off by simply *not linking against -lpthread*. // In that situation, the

Hi, The old llvm::sys::RWMutex use platform-specific lock mechanism to implement read/write lock. For example, SRWLock on Windows and pthread read/write lock on *nix systems. However, in comparison with the approach that implement read/write lock base on std::atomic, the old methods not only has potential performance issue(Sorry I can't provide concrete evidence, any benchmark result is

Hello, I have an application that uses Clang and LLVM wrapped in a DLL. Last week I was debugging reported issues with Microsoft Application Verifier<http://www.microsoft.com/download/en/details.aspx?id=20028> that were related to how critical sections are handled. The issues are caused by critical sections that are either still active when heap blocks are deleted or the DLL is unloaded.

David, Your fix sounds fine to me. Please apply. --Owen On Feb 14, 2010, at 6:30 AM, David Chisnall wrote: > Hi Vincent, > > This is an LLVM issue, rather than a clang issue, so llvmdev is the appropriate mailing list for this report. > > Your fix looks semantically valid, but it would be cleaner to only create and destroy the pthread_rwlockattr_t if it is actually needed,

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

Good day Nathan, If your using the stock GCC with Solaris, I am sorry to inform you its broken, Please see: http://llvm.org/docs/GettingStarted.html#brokengcc Please be warned as your get miss compiles and things will do strange `stuff`. As can be seen here, the reverse is true for both the GNU binutils and XPG4 versions of `nm' : -bash-3.2$ /usr/xpg4/bin/nm -p -u `find . -name

(Sorry, previous post got sent by accident. This is the real one) Folks, Here's some timing results looking at LLVM when it uses libLLVMCore.o vs. libLLVMCore.a. We're trying to decide which way to go and thought some data would help. The net of it is that using libLLVMCore.a is cheaper in both time and size of executables. We save 37 seconds on linking LLVMCore and about 1 minute 30

Hi I am not a good programmer but for my project i have to use llvm to generate CFG for c programs where i have a mapping from IR instruction in CFG to their respective c instruction. After surfing a in source of llvm i did the following change in printInstruction() function in llvm/lib/VMCore/AsmWriter.cpp file. .....void AssemblyWriter::printInstruction(const Instruction &I) { if

Folks, Here's some timing results looking at LLVM when it uses libLLVMCore.o vs. libLLVMCore.a. We're trying to decide which way to go and thought some data would help. The data below was generated from using GCC 3.4.6 and binutils 2.15.92 on Fedora Core 3 running on a 2.4GHz Dual Xenon with 1GB of ram. Time With libLLVMCore.a With LLVMCore.o Link Real Time (-j 1) 2m12.592s 3m51.750s

I've managed to compile LLVM & Clang on windows using command prompt and using it in MinGW (MSYS Shell). I've done this multiple times, following many different instructions, ranging from the Getting started page for clang, the llvm.org official getting started page, and even the attached guide written by someone else on the llvmdev email list (

Has anything been done about this issue since Reid first mentioned it? I think I'm getting bitten by it. -- John T. Reid Spencer wrote: > The recent change in the library structure to make libLLVMCore.a instead > of LLVMCore.o has caused a little fallout. The problem is LLVM tools > that take a --load option to load a module dynamically may now cause > those modules to fail to