similar to: [LLVMdev] CMake.html corrections

Hi Óscar, On 14 March 2010 15:06, Óscar Fuentes <ofv at wanadoo.es> wrote: > Victor Zverovich <victor.zverovich at googlemail.com> writes: > > > Hi llvm-dev, > > > > Attached are two patches for the LLVM cmake build system. > > > > The first one adds static runtimes (MT and MTd) to the list of runtimes > for > > the MSVC build. > >

Hi llvm-dev, Attached are two patches for the LLVM cmake build system. The first one adds static runtimes (MT and MTd) to the list of runtimes for the MSVC build. The second one makes it possible to use llvm_config in external projects. In this patch I took the liberty of changing the format of LLVMLibDeps.cmake to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*.

On 17 March 2010 19:07, Óscar Fuentes <ofv at wanadoo.es> wrote: > Victor Zverovich <victor.zverovich at googlemail.com> writes: > > >> > Attached are two patches for the LLVM cmake build system. > >> > > >> > The first one adds static runtimes (MT and MTd) to the list of > >> > runtimes for the MSVC build. > >> >

Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise,

Victor Zverovich <victor.zverovich at googlemail.com> writes: > Hi llvm-dev, > > Attached are two patches for the LLVM cmake build system. > > The first one adds static runtimes (MT and MTd) to the list of runtimes for > the MSVC build. This seems not to be as easy as you put it. It was discussed here recently: From: José Fonseca Subject: [PATCH]: MSVC build enhancements

Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich <victor.zverovich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > >

Hi All, The proposed patch makes possible to use LLVM's CMake build infrastructure (most importantly add_llvm_library and add_llvm_executable macros) from the project that has llvm in a subdirectory. For example: demo/ llvm/ demo.cpp CMakeLists.txt where CMakeLists.txt is as follows: # ----------------------------- Start of CMakeLists.txt

Victor Zverovich <victor.zverovich at googlemail.com> writes: >> > Attached are two patches for the LLVM cmake build system. >> > >> > The first one adds static runtimes (MT and MTd) to the list of >> > runtimes for the MSVC build. >> >> This seems not to be as easy as you put it. It was discussed here >> recently: >> >>

Hi Jeffrey, You are right that the generated copy constructor is used for const_iterator. I have added a comment clarifying this. Also I have added the tests you suggested and corrected the comparison operators. Please find attached the updated patches. Best regards, Victor 2009/11/3 Jeffrey Yasskin <jyasskin at google.com> > +template <bool, typename True, typename False> >

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

Albert Graef <Dr.Graef at t-online.de> writes: > Victor Zverovich wrote: >> I am considering a possibility of using LLVM JIT for an algebraic >> modelling language. I have already done some prototyping following the >> Kaleidoscope tutorial and currently thinking of how to connect the >> jitted code to a runtime library (for this language) which I would like

+ // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi Jeffrey, > You are right that the generated

Hi all, Following the example from http://llvm.org/docs/GoldPlugin.html#example1 gives the following error on Ubuntu Karmic: /usr/bin/ld: error: a.a: no archive symbol table (run ranlib) /usr/bin/ld: /usr/lib/crt1.o:../sysdeps/i386/elf/start.S:115: error: undefined reference to 'main' /usr/bin/ld: b.o: in function foo1:b.c(.text+0x4): error: undefined reference to 'foo2'

Hi, The question about the name mangling gave me an idea that it can be used to automate registration of DLL functions. Instead of manually creating Function objects specifying a return type and argument types which is error-prone and time-consuming one can get a list of functions exported from a DLL using Windows API, demangle each name and construct a Function object from it. Is there any

Dear all, The first of the proposed patches (DenseMapIterator.patch) forbids implicit conversion of DenseMap::const_iterator to DenseMap::iterator which was possible because DenseMapIterator inherited (publicly) from DenseMapConstIterator. Conversion the other way around is now allowed as one may expect. The template DenseMapConstIterator is removed and the template parameter IsConst which

On 5 April 2010 10:24, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi all, > Following the example > from http://llvm.org/docs/GoldPlugin.html#example1 gives the following error > on Ubuntu Karmic: > /usr/bin/ld: error: a.a: no archive symbol table (run ranlib) > /usr/bin/ld: /usr/lib/crt1.o:../sysdeps/i386/elf/start.S:115: error: > undefined reference

Victor Zverovich <victor.zverovich at googlemail.com> writes: > The question about the name mangling gave me an idea that it can be used to > automate registration of DLL functions. Instead of manually creating > Function objects specifying a return type and argument types which is > error-prone and time-consuming one can get a list of functions exported from > a DLL using

+template <bool, typename True, typename False> +struct If { typedef True Result; }; + +template <typename True, typename False> +struct If<false, True, False> { typedef False Result; }; These should probably go into include/llvm/Support/type_traits.h. In C++0x, this is named "conditional" (section 20.6.7), so I think you should use the same name, despite the standard

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

Dear All, I am considering a possibility of using LLVM JIT for an algebraic modelling language. I have already done some prototyping following the Kaleidoscope tutorial and currently thinking of how to connect the jitted code to a runtime library (for this language) which I would like to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic' option as suggested in the