similar to: [LLVMdev] Build failure for latest source

Probably your g++ compiles x86_64 binary by default, but i686 dylib is supplied? Try: g++ -m32 e.cpp /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/libllvmgcc.dylib - D. 2012/1/22 Arpan Sen <arpansen at gmail.com>: > Hi, > > I am trying to use some LLVM API in my C++ code, and I end up getting linker > errors. I am

Hi, I am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It is the CreateGlobalStringPtr which is throwing the error. This is LLVM 3.0. Here's the codeI am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It

On Mon, 12 Feb 2007, Carsten Reuter wrote: > I am trying to build and install LLVM onto a current Debian Linux system > using gcc4 frontend binaries for Red Hat Enterprise Linux4/x86 . > Using the commands below the Build finishes, ignoring an error that > comes up again when I try to make install. > See the messages below. I have no good feeling about the "-i -k" options.

Hi, I am trying to build and install LLVM onto a current Debian Linux system using gcc4 frontend binaries for Red Hat Enterprise Linux4/x86 . Using the commands below the Build finishes, ignoring an error that comes up again when I try to make install. See the messages below. I have no good feeling about the "-i -k" options. Is it OK? Thank you in advance for any advice and best

Hi Chris, > What flavor of iterators do you want to pass in? vector or > smallvector? If so, a pointer to the first element + extents is fine. I was passing a std::vector in. And you are quite right, first element + size works like a charm. Since I am using a vector of uint64_t's instead of Value*, I did need to add an extra version of getIndexedType(), taking a uint64_t* instead

Hi all, once more with the patch inline for easy review. I did not include the argpromotion pass here, since it's not the main topic of this post. Gr. Matthijs Index: lib/VMCore/Instructions.cpp =================================================================== --- lib/VMCore/Instructions.cpp (revision 53672) +++ lib/VMCore/Instructions.cpp (working copy) @@ -1068,41 +1068,6 @@

Hi all, currently, GetElementPtrInst has a method getIndexedType, which has a templated variant. You pass in a begin and an end iterator, and it will find the indexed type for those. However, both iterators must iterate over Value*. For some argpromotion code, I would like to pass in iterators that iterate over unsigneds instead of Value*. I currently solve this by transforming my

Hello, Ferad. > `.gnu.linkonce.t._ZN4llvm12SCEVExpander6expandEPNS_4SCEVE' referenced > in section `.rodata' of > /home/ferad/llvm/llvm-obj/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o): > defined in discarded section > `.gnu.linkonce.t._ZN4llvm12SCEVExpander6expandEPNS_4SCEVE' of >

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

On 3/30/2017 9:03 PM, Reid Kleckner via llvm-dev wrote: > On Thu, Mar 30, 2017 at 5:57 PM, Edward Diener via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Actually just doing: > > clang++ -c t.cpp -o t.o --target=x86_64-windows-msvc -fmsc-version=1900 > clang++ t.o -o t.exe --target=x86_64-windows-msvc

Hi llvm-dev, Our code base has a ancient copy of llvm (ver 3.5.1), and it uses the LLVM code gen for some domain-specific language. The previous dev left a global lock around the usage of LLVM code gen stating that because LLVM code gen can only be accessed single-threaded it needs to be protected with this global lock. But now this lock has caused some perf issues as we pretty much lose

Thank you Johannes, I looked it up and it seems that we're creating one LLVMContext per compilation "unit", not sure if that matters. i.e. there's no single globally shared LLVMContext object. Is LLVMContext *the* concurrency isolation (or unit) here? On Wed, Apr 3, 2019 at 6:34 PM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > Do you use one llvm context or one

On Jul 22, 2008, at 11:54 PM, Matthijs Kooijman wrote: > Hi Chris, > > >> I'd prefer to not turn this into a template. Why not just define a >> version that takes an array of uint64_t's or something like that? > because I want to be able to pass in iterators. I could define a > version that > takes std<uint64_t>::iterators, but next thing we know, we

On 1/5/2013 8:01 PM, Justin Holewinski wrote: > > On Sat, Jan 5, 2013 at 5:59 PM, Edward Diener > <eldlistmailingz at tropicsoft.com <mailto:eldlistmailingz at tropicsoft.com>> > wrote: > > On 01/05/2013 01:11 PM, Dmitri Gribenko wrote: > > On Sat, Jan 5, 2013 at 7:48 PM, Edward Diener > <eldlistmailingz at tropicsoft.__com >

Hi, I'm having a hard time finding an answer to what I assume is a very basic idea. I'm trying to produce this llvm code using the LLVM api: %myString = alloca [13 x i8], i32 13 store [13 x i8] c"Hello world.\00", [13 x i8]* %myString %tmp1 = getelementptr [13 x i8]* %myString, i32 0, i32 0 %tmp2 = call i32 (i8*, ...)* @printf( i8* %tmp1 ) nounwind A simple Hello

On Sat, Jan 5, 2013 at 11:08 PM, Edward Diener < eldlistmailingz at tropicsoft.com> wrote: > On 1/5/2013 8:01 PM, Justin Holewinski wrote: > >> >> On Sat, Jan 5, 2013 at 5:59 PM, Edward Diener >> <eldlistmailingz at tropicsoft.**com <eldlistmailingz at tropicsoft.com><mailto: >> eldlistmailingz@**tropicsoft.com <eldlistmailingz at

On 01/05/2013 01:11 PM, Dmitri Gribenko wrote: > On Sat, Jan 5, 2013 at 7:48 PM, Edward Diener > <eldlistmailingz at tropicsoft.com> wrote: >> I actually found out that llvm/configure will choose clang if it is >> found in the path. This contradicts what is written at >> http://llvm.org/docs/GettingStarted.html#requirements, where it says it >> will use the

Building of llvm with gcc-4.5.2-1 gives these warnings: 1) Building FileManagerTest "llvm[4]: Compiling FileManagerTest.cpp for Debug+Asserts build C:/Programming/VersionControl/llvm/tools/clang/unittests/Basic/FileManagerTest.cpp: In member function 'virtual void<unnamed>::FileManagerTest_NoVirtualDirectoryExistsBeforeAVirtualFileIsAdded_Test::TestBody()':

On Sat, Jan 5, 2013 at 5:59 PM, Edward Diener < eldlistmailingz at tropicsoft.com> wrote: > On 01/05/2013 01:11 PM, Dmitri Gribenko wrote: > >> On Sat, Jan 5, 2013 at 7:48 PM, Edward Diener >> <eldlistmailingz at tropicsoft.**com <eldlistmailingz at tropicsoft.com>> >> wrote: >> >>> I actually found out that llvm/configure will choose

On 6/8/2015 10:10 PM, Tim Northover wrote: > On 8 June 2015 at 17:53, Edward Diener <eldlistmailingz at tropicsoft.com> wrote: >> How can I tell at compile time through predefined macros whether libc++ >> includes/supports the C++14 header file shared_mutex ? > > I doubt it's even theoretically possible. Clang can be used with > multiple standard libraries, and