search for: vstudio

Hello LLVMers, For the windows side of my team's product, I use the VStudio project files included in the LLVM tree (which are VStudio 2k3 files). I just switched over to the SVN sources yesterday and spent some time working with those project files to get things to build cleanly on my system. We use VStudio 2k5, so I have to go through a conversion process which may be t...

Hi Chuck, On Wed, 2007-07-25 at 11:16 -0700, Chuck Rose III wrote: > Hello LLVMers, > > > > For the windows side of my team’s product, I use the VStudio project > files included in the LLVM tree (which are VStudio 2k3 files). I just > switched over to the SVN sources yesterday and spent some time working > with those project files to get things to build cleanly on my system. > We use VStudio 2k5, so I have to go through a conversion pr...

Hola Reid, Cool deal. I think I have all the bugs worked out as I'm building cleanly now in one "build all" pass as opposed to two. I'm going to integrate and test the results with our system. Will the patch process be sufficient for this kind of change (~350K of VStudio XML goo)? Should I request commit access, if at least for the vstudio stuff? Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Spencer Sent: Wednesday, July 25, 2007 11:26 AM To: LLVM Developers Mailing Lis...

Hola LLVMers, Our project is cross platform and on Windows we use VStudio 2005. VStudio presents a couple of issues related around it's STL implementation and also it's non-respect for the no-return semantic of abort(). I've fixed it locally, but I'd like to send a patch so I don't have to do this every time I update from the source repository....

...uot; default: abort(); break;\n"; ... OS << " };\n"; OS << " return 0; // Visual Studio 2005 does not respect the no-return semantics of abort\n"; OS << "}\n\n"; Need this because otherwise the emitted function will fail to compile in VStudio. PredicateSimplifier.cpp: The other problem is subtle. In the Edge class (for example) this function will fail to compile in debug. iterator find(unsigned n, ETNode *Subtree) { iterator E = end(); for (iterator I = std::lower_bound(begin(), E, n); I != E &...

Nope, it generates an error, not a warning-as-error. (LLVM generates a whole host of warnings when run through the VStudio STL implementation). I misspoke earlier about VStudio ignoring noreturn. I investigated further and found that the implementation of abort in VStudio 2k5 is not tagged noreturn, hence the error. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu on behalf of me22 S...

On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed it loca...

...;; > ... > OS << " };\n"; > OS << " return 0; // Visual Studio 2005 does not respect the > no-return semantics of abort\n"; > OS << "}\n\n"; > > Need this because otherwise the emitted function will fail to compile in > VStudio. > This might be more subtle than it seems. I'm assuming that since that actually fails, you have warnings-as-errors on. In compilers with good flow analysis that do have noreturn abort, the extra return should trigger an "unreachable code" warning, which will also prevent compil...

> The x86-64 one probably doesn't work for Winodws. That's likely the > issue. Well, x86-64 stub was never ported to intel assembler, I expect to see 32-bit one used on windows64. In general, the whole windows64 support is missed mainly due to crazy calling convetion invented by Microsoft. So, all calls from code being JITed to external functions will be clearly broken (if they

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov

Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think

Hello, Evan > I think a Win64 version of X86CompilationCallback{2} is still needed. > Also, it's not clear to me how to force a non-Windows CC. It may > require some FE extension to support it? Well, as currently we don't have windows64 support in FE correct (non-windows) CC will be set automatically. -- WBR, Anton Korobeynikov

...esponse Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it from being overzealous. Second, I tried putting the code you gave in my app, and I got into a wild goose chase of include files not being found. Finally ended with: <myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(2...

On Sep 5, 2007, at 5:08 PM, Chuck Rose III wrote: > Hola Dale, > > > > I spent some time walking through what’s going on with a friend of > mine from VStudio. Category is given 2 bits in the APFloat class > definition. It’s sign extending the enum value for the comparisons > when it loads it out of the class, so the 2 becomes a -2 and the > comparison fails. He sent me a piece of code which I might be able > to use to force the is...

...rough some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by VStudio and I’m creating another function foo > via LLVM JIT which is going to call into bar. This has been working > for me for a long time on win32 and also under xcode of course. > I’ve included the code that generates the situation at the bottom. > Some questions (which may be re...

...deTys = DAG.getVTList(MVT::Other, MVT::Flag); Thanks! Chuck. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Friday, February 15, 2008 9:35 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] LLVM2.2 x64 JIT trouble on VStudio build On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise le...

Dale Johannesen wrote:- > >I spent some time walking through what?s going on with a friend of > >mine from VStudio. Category is given 2 bits in the APFloat class > >definition. It?s sign extending the enum value for the comparisons > >when it loads it out of the class, so the 2 becomes a -2 and the > >comparison fails. He sent me a piece of code which I might be able > >to use...

...esponse Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it from being overzealous. Second, I tried putting the code you gave in my app, and I got into a wild goose chase of include files not being found. Finally ended with: <myabsolutepathroot>\llvm\target\x86\x86instrinfo.h(2...

...9;m debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going to call into bar. This has been working for me for a long time on win32 and also under xcode of course. I've included the code that generates the situation at the bottom. Some questions (which may be really brain dead) are...