similar to: [LLVMdev] Advice on a VStudio specific patch

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

Here are the two problem areas: RegisterInfoEmitter.cpp // Emit the subregister + index mapping function based on the information // calculated above. OS << "unsigned " << ClassName << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" << " switch (RegNo) {\n" << " default: abort(); break;\n"; ...

Hello, I have just updated my svn copy of the llvm/clang repositories after quite a long time of inactivity, and found it not compiling on Windows with Visual Studio 2008. The incriminated file is: llvm/lib/MC/MCModule.cpp Where several calls to "std::lower_bound" are made, like: atom_iterator I = std::lower_bound(atom_begin(), atom_end(),

On Thu, Jul 4, 2013 at 12:48 AM, Benoit Perrot <benoit.noe.perrot at gmail.com>wrote: > Hello, > Hi Benoit, > I have just updated my svn copy of the llvm/clang repositories after quite > a long time of inactivity, and found it not compiling on Windows with > Visual Studio 2008. > > The incriminated file is: > > llvm/lib/MC/MCModule.cpp > > Where several

Hi, I upgraded the Visual Studio SLN file to work with 2005 and had to make some changes. The first two have to do with the fact that the debug implementation of 2005's STL does all sort of validation, that's why they didn’t show up on 2003. I'm not set up for patch submission yet, but if somebody has time to review these changes that'd be greatly appreciated. Meanwhile

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 the cause of some

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

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.

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

I'm not sure what causes this. Everything builds fine in Release mode but when I try to do a Debug build I get an error in Transforms (which causes all dependant projects to fail as well). I'm not exactly sure what causes the error, I'll try to investigate tomorrow (unless someone can figure out what it is by then). Below is the output from VS: ------ Build started: Project:

On 31/05/07, Chuck Rose III <cfr at adobe.com> wrote: > Here are the two problem areas: > > RegisterInfoEmitter.cpp > > // Emit the subregister + index mapping function based on the > information > // calculated above. > OS << "unsigned " << ClassName > << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" >

Hola LLVMers, We saw a problem with some code in LiveIntervalAnalysis.h/.c which we've fixed locally. We'd like to get a patch to the mainline and want to know how you'd like it fixed. A couple of things come together to cause the problem: struct Idx2MBBCompare { bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) const { return LHS.first <

It compiles successfully with VC++ 7.1. You are apparently using VC++ 8.0, otherwise known as the Whidbey beta. The cause is no doubt due to bugs in Whidbey and this isn't the first one encountered. I'm sorry, but I cannot support beta Microsoft products (if only because I refuse to have them anywhere near my computer). All I can suggest is that you do a 'clean solution'

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: > Could

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

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 > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

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

> 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

Hola Jaap, I'm curious which version of the source are you working with? It sounds like you and I were working on the same problem yesterday, but I didn't see those particular compiler errors. (I saw a couple of other ones for which I submitted a patch). I did see errors like the ones you saw with the CVS LLVM 2.0 sources a while back, namely the missing < operator and the debug STL