similar to: [LLVMdev] Fixed alloca.h for Visual C

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

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. --------------

Hello, with the patches you accepted last week, everything now works with two one-line modifications. One is a missing include in a windows specific platform file and the other is a definition of a symbol I need to trick the linker (as discussed before)... The attached file is the complete diff between my version and the CVS. If you want to put my visual studio project files into the CVS,

I moved my own llvm tree out of the way and tried to get a fresh copy from cvs and build everything from scratch... and it worked! apart from one little problem, a file was moved and should be removed from the project files -- here is a patch. There is a small problem with submitting patches for the .vcproj files - VS saves them with CRLF line endings but the CVS versions appear to have only

Chris Lattner wrote: > The two patches I didn't apply are the one that affects the interpreter > (I'll let Brian tackle it as he's the interpreter guy), and this one: > > =================================================================== > RCS file: /var/cvs/llvm/llvm/include/llvm/CodeGen/MachineBasicBlock.h,v > retrieving revision 1.39 > diff -u -r1.39

Hello, This is my first post on this mailing list, so bear with me... My name is Morten Ofstad and I work for Hue AS (www.hue.no), a company that makes 3D Visualization software. We are looking into using LLVM for JIT compiling shader programs, to replace our own (slow) VM. A requirement for this is that we can compile LLVM in VS7.1, so I contacted Paolo Invernizzi to find the status of his

On Tue, 12 Oct 2004, Morten Ofstad wrote: > This is my first post on this mailing list, so bear with me... My name > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > makes 3D Visualization software. We are looking into using LLVM for JIT > compiling shader programs, to replace our own (slow) VM. A requirement Neat! > for this is that we can compile LLVM in

-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041025/d290c6e0/attachment.txt>

Hi, you might or might not want to take these patches, as they are basically just meant to shut VS up. For LLVM this does not matter much, but when I include the public headers in my own app I prefer not to get tons of warnings, so I fixed the ones I got all the time... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

On Tue, 12 Oct 2004 14:01:21 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > On Tue, 12 Oct 2004, Morten Ofstad wrote: > > > This is my first post on this mailing list, so bear with me... My name > > is Morten Ofstad and I work for Hue AS (www.hue.no), a company that > > makes 3D Visualization software. We are looking into using LLVM for JIT > >

Hi, several of the patches I submitted last week have not yet been applied, and most of it was really uncontroversial stuff like adding some #includes and some typecasts, fixing alloca for visual C etc. I guess I just wrote too many mails so it was lost in the process, so here is a diff which includes all changes I have made, except those related to hash_map differences since my solution

On Mon, 25 Oct 2004, Morten Ofstad wrote: > several of the patches I submitted last week have not yet been applied, > and most of it was really uncontroversial stuff like adding some > #includes and some typecasts, fixing alloca for visual C etc. Oops, sorry about that. :( > I guess I just wrote too many mails so it was lost in the process, so > here is a diff which includes all

We could also do the "cvs admin -kb" thing on all the project files so that cvs won't do keyword expansion or line ending conversion. Thoughts? Reid. On Mon, 2004-11-08 at 07:36, Jeff Cohen wrote: > You have to use a version of CVS that's specifically built for Windows. > You can find prebuilt Windows binaries at cvshome.org. The cygwin > supplied CVS no doubt

defining __STDC_LIMIT_MACROS on the command line is not really necessary for Visual Studio, and is a bit of a pain when you want to include the LLVM headers from your own project, so I moved the check a bit down into the Unix case to avoid the hassle... Here is a patch On a side note, everything is going well so far with integrating LLVM into our application - I was very happy when I found

You have to use a version of CVS that's specifically built for Windows. You can find prebuilt Windows binaries at cvshome.org. The cygwin supplied CVS no doubt thinks it's running on Unix, so naturally it won't convert line endings. On Mon, 08 Nov 2004 16:23:30 +0100 Morten Ofstad <morten at hue.no> wrote: > Jeff Cohen wrote: > > > Are you sure your CVS is

Here is a patch -- on a side note I see that a patch checking _MSC_VER has gone in which defines a lot of limits that should really come from <limits.h> ... Anyone care to comment on this? m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL:

Jeff Cohen wrote: > Are you sure your CVS is configured correctly? On Windows, CVS > automatically converts between LF and CR/LF line endings. I sent a > patch to remove all CRs from the repository because when I checked out > the files on Windows, every line had two CRs and a single LF. When VS > saved a modified project file, the extra CR went away, causing every > line to

Paolo Invernizzi wrote: > I submitted a patch with a std::vector, but was commited as alloca ;-P for the other problem? I made a nice clean patch using std::vector in LiveVariables.cpp now, which I include with this message... By the way, where do you submit the patches if not to the mailing list? I thought I should post here so Paolo and others interested in the porting effort can apply

On Tue, 26 Oct 2004, Morten Ofstad wrote: > the <functional> is needed because of this declaration: > > struct MachineBasicBlock2IndexFunctor > : std::unary_function<const MachineBasicBlock*, unsigned> { > > How can it be moved?? You're right, it can't, except that MachineBasicBlock2IndexFunctor is dead, so I nuked it. > removing the <algorithm>

OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JIT.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>