On Thu, 4 Nov 2004 22:38:26 -0600 (CST) Chris Lattner <sabre at nondot.org> wrote:> > > Also, the llvm.suo file should not be in the repository. This has > > per-user configuration settings for VS. I'm surprised you even knew it > > was there to be checked in, as it's a hidden file. This file had > > hard-coded paths to Morten's setup, and even had his breakpoints in it. > > Ok, nuked. > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020250.htmlAnd not to be picky, but all the debug/release directories ought to be nuked also. No files will ever be checked in these directories, and cvs won't even create them on checkout because they are empty. VS will happily create them when needed.> > starting fibonacci(10) with JIT... > > Result: 55 > > I assume this is correct. > > Yup, this is right! Does this mean that you guys don't need the hack to > pull in the X86 backend by force on Win32?Morten will have to answer this one.> -ChrisI'm attaching the build log from VS. There are several dozen compilation warnings that you may or may not want to fix. -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: application/octet-stream Size: 24620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041104/e20d65e0/attachment.obj>
On Thu, 4 Nov 2004, Jeff Cohen wrote:> path as it uses execvp. At least on Unix. I have no idea what it does > on Windows as I could not get the source used to build the Windows > version (the installer claimed it installed the source, but it didn't).Wierd.> The link of tablegen fails still fails, though, complaining of a missing > support.lib. This is due to a bug in the debug configuration of > tablegen (and is not present in the release configuration). Patch > attached.Ok, applied, thanks! http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020249.html> Watching this thing build, what comes to mind is that it would go a > whole lot faster if we could use precompiled header files.I don't know of a good way to do that. Personally, I'm a big fan of just putting as little into #includes as possible, instead of relying on PCH.> The build finally gets to Fibonacci and fails with: > > c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2065: 'args' : undeclared identifier > c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2228: left of '.IntVal' must have class/struct/union type > > I don't how this compiles with gcc. "args" is mispelled. Should be > "Args". Patch attached for this also.This was a transient bug in CVS that you must have just been unlucky to get, sorry about that.> Also, the llvm.suo file should not be in the repository. This has > per-user configuration settings for VS. I'm surprised you even knew it > was there to be checked in, as it's a hidden file. This file had > hard-coded paths to Morten's setup, and even had his breakpoints in it.Ok, nuked. http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020250.html> starting fibonacci(10) with JIT... > Result: 55 > I assume this is correct.Yup, this is right! Does this mean that you guys don't need the hack to pull in the X86 backend by force on Win32? -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Thu, 4 Nov 2004, Jeff Cohen wrote:> And not to be picky, but all the debug/release directories ought to be > nuked also. No files will ever be checked in these directories, and cvs > won't even create them on checkout because they are empty. VS will > happily create them when needed.Done.> > > starting fibonacci(10) with JIT... > > > Result: 55 > > > I assume this is correct. > > > > Yup, this is right! Does this mean that you guys don't need the hack to > > pull in the X86 backend by force on Win32? > > Morten will have to answer this one.ok.> I'm attaching the build log from VS. There are several dozen > compilation warnings that you may or may not want to fix.I fixed a bunch of them, see the llvm-commits list. I don't agree with the whole "lets warn if you negate an unsigned number" warning, and I don't know what to do about deprecated hash_map and friends, but most of the rest are fixed. -Chris -- http://llvm.org/ http://nondot.org/sabre/
First of all, I've been working at the university for a few days, so I haven't read my hue.no email -- sorry I wasn't there to help when you tried to use my project files. But it seems it turned out well, thanks a lot to Jeff Cohen for cleaning up my mess! First of all, the gnu tools -- I copied them into the llvm/win32 directory from the original (default) installation location because I did not want any absolute paths in the project files. I also don't want the project to pull in any old flex or bison along the path, since I have cygwin in my path. The readme.txt is missing some details on how to install these tools because the first archive I sent to Reid had all the tools in it. I'm happy Jeff sorted it out, but it would be nice if he could also write some instructions in the readme on how he did it.>>The link of tablegen fails still fails, though, complaining of a missing >>support.lib. This is due to a bug in the debug configuration of >>tablegen (and is not present in the release configuration). Patch >>attached.This is a bit strange, it was building fine on my system... Anyway, thanks for the fix.> Yup, this is right! Does this mean that you guys don't need the hack to > pull in the X86 backend by force on Win32?There is a forced symbol reference in the fibonacci project files to pull in the x86 backend. If you leave this one out, it still works because it uses the interpreter instead - but of course it's 100 times slower... m.