similar to: [LLVMdev] HowToUseJIT.cpp - file: 'llvm/ADT/iterator': No such file or directory

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 10:20:39 +0200 > >I'm using scons to generate that files from .in files. I implemented in it >the configure check regarding iterators, hash and so on... >something like: > Hey, you've found the tool that makes it possible to generically reading Makefiles... Cool - The tool I've

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 11:18:00 +0200 >If VC6 is not doing something wrong with templates... ;-/ As far as I know is template handling a part of some C++ ISO standard. Then, MS should adhere to this... However, what you objects against is that MS didn't implement STL the way STL should be implemented. And the reason to

It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always

Aaron Gray wrote: > Hi, > > I partly built LLVM on Cygwin yesterday and it was fine as far as it > went. But after doing a svn update today I am getting the following > warning on every compile :- > > > llvm[3]: Compiling LowerAllocations.cpp for Debug build > /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: > -fPIC ignored for

Hi, I partly built LLVM on Cygwin yesterday and it was fine as far as it went. But after doing a svn update today I am getting the following warning on every compile :- llvm[3]: Compiling LowerAllocations.cpp for Debug build /usr/src/llvm/lib/Transforms/Utils/LowerAllocations.cpp:1: warning: -fPIC ignored for target (all code is position independent) This maybe happening on other targets too.

I finally managed to compile a working fibonacci example (using the interpreter, I'm still working on porting the x86 backend). The final problem was that I couldn't find a way to force the linker to include the Dominators.obj file since there were no references to it. There is an option to the linker to stop it from stripping unreferenced code, but it still doesn't pull the object

On Thu, 14 Oct 2004, Morten Ofstad wrote: > I finally managed to compile a working fibonacci example (using the > interpreter, I'm still working on porting the x86 backend). The final > problem was that I couldn't find a way to force the linker to include > the Dominators.obj file since there were no references to it. There is > an option to the linker to stop it from

Uh... this may be a silly question, but why can't you include <stdio.h>? It'd be much better than <iostream>. Anyway, I think I'll try this weekend to come up with my own way of building on Win32. I prefer that building on Windows depends only on Microsoft and GNU tools, and the fewer of the latter the better. My gut instinct is to capture all the files generated by

Hi, I saw that Nick Lewycky removed the LLVM portable hash_map and hash_sets. My research group was relying on those classes. What replaces hash_map and hash_set? The LLVM implementation was very convenient as there is no equivalent in STL, and Microsoft's implementation had a different name, as does the C++ 0X implementation. Thanks. Tom Jablin

Hi, Libc++ has been shipping the <ext/hash_set>, <ext/hash_map> and <ext/__hash> headers for a while and they are deprecated. Those headers contain data structures like __gnu_cxx::hash_map that have replacements like std::unordered_map. I would like to remove those headers. I've put up a patch for review but I won't commit it until we have a sort of plan because I know

Hi, I just started with LLVM so I'm not sure who's responsible for portability. Anyways, I found the following problems trying to compile llvm rev 94074 with the solution generated using cmake 2.8 (including the clang front end) on 32bit vista: lib/system Errno.cpp : had to add "#undef HAVE_STRERROR_R" raw_ostream.cpp: had to add "#undef HAVE_UNISTD_H"

OK. I strongly support that sentiment. Paolo, could you send me your procedure for building under Windows? I haven't tried to build anything but System/Win32 so far. On Fri, 24 Sep 2004 07:52:23 -0700 Reid Spencer <reid at x10sys.com> wrote: > I'll wait for the research. We should try, as much as possible, to make > it work with just what the compiler provides and without

I don't know if Paolo submitted his patches for these files, but they are not in the CVS -- I've chosen a slightly different strategy, adding a case that checks if the compiler is MSVC instead of adding HAVE_FINITE_IN_FLOAT_H and HAVE_ISNAN_IN_FLOAT_H to the config.h file. I don't know which is the best approach, but this is the minimal patch to make it work... m. --------------

Here is the pre-pre-pre alpha of the file, llease be kind <g> I give up on TableGen... cannot build the flex/bison emitted files ;-( With my hacked version of the checkout the script build Fibonacci.exe and HowToUseJIT.exe among with the proper libraries. I included also a demo version of the HowToUseJIT Visual studio project generated by the script. You can debug the program in the

When I ran configure after updating, I get various errors. First: % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc checking for a BSD-compatible install... /usr/bin/install -c checking build system type... i386-unknown-freebsd5.2.1 checking host system type... i386-unknown-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad

Hi, i had the same troubles on Vista and on Win7... cmake fails on some tests (you should see this in the log) due to m$ UAC (or whatever the name is) and uses not-so-sane default values. You have to start a visual c-command prompt (to make sure it gets the right paths) with administrator privileges (!) , than cmake works fine and you get a correct config.h. best regards, Thomas 2010/1/22

Jeff Cohen wrote: >But I compiled that under vc7.1 as it was! > > ;-(( Probably is an implicid includes, but I'm using the STLPort standard library for LLVM (because it's not possible to use hash_map and hash_set of microsoft) cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /DHAVE_WINDOWS_H

The scons file that I posted yesterday is broken... I've not taken in account the commit of 2 days ago that modified *iterator.in* and friends. I've updated it and now it works again; inside it you can find comments about what files currently are NOT compiled and why (hint appreciated!) Attached to this email you can find it and a new series of patches against current CVS, that I hope

Hi! I've started looking porting our application which uses LLVM JIT to using LLVM 9 (9.0.1). To begin, I tried running the HowToUseJIT.cpp (example directory) program and it fails with a segfault: ./HowToUseJIT We just constructed this LLVM module: ; ModuleID = 'test' source_filename = "test" Running foo: Segmentation fault (core dumped) Running it through GDB:

<algorithm> works too. On Fri, 24 Sep 2004 10:09:21 -0500 Alkis Evlogimenos <alkis at cs.uiuc.edu> wrote: > On Fri, 2004-09-24 at 09:43, Paolo Invernizzi wrote: > > Jeff Cohen wrote: > > > > >But I compiled that under vc7.1 as it was! > > > > > > > > ;-(( > > > > Probably is an implicid includes, but I'm using the