[LLVMdev] ThisCall / Compilation problems

Žiga Osolin ziga.osolin at gimb.org
Fri Dec 15 09:29:00 PST 2006


David Shipman pravi:
> Hi all,
>
> A few things.
> Firstly, I've got a working implementation of the X86ThisCall calling 
> convention, but I'm unsure how to go about submitting it.
> (I'm not really sure how to go about creating patch files etc, but 
> would like to contribute to the project).
I can't wait to see thiscall conversion:)
>
> Also, I'm using MS Visual C++ Express, and there are a few things that 
> stop llvm1.9 (and the current CVS release) from compiling
> correctly - once again, not sure how to submit, but here are the main 
> things -
>
> In SelectionDAGNodes.h
>
>        StoreSDNode(SDOperand Chain, SDOperand Value, SDOperand Ptr, 
> SDOperand Off,
>               ISD::MemOpAddrMode AM, bool isTrunc, MVT::ValueType SVT,
>               const Value *SV, int O=0, unsigned Align=0, bool Vol=false)
>
> SDOperand Value should really be SDOperand value (lower case), since 
> Value is already a defined classname.
> Not sure if this is really a 'bug', but it does cause errors in some 
> compilers.
Yes, I know the problem. I submited a patch not that long ago that made 
compiling ov Visual Studio 7.1 possible. As I have found out later, it
did not work on Visual Studio 8 ... there are quite a few errors.
>
> Regarding the new stream wrappers in the current CVS version (in 
> Support/Streams.h)
> A lot of errors in VC++ Express (not sure about other MSVC versions).
>
> Adding
>
> #ifdef _MSC_VER
> #include <iostream>
> #endif
>
> to Streams.h seems to remedy this, but presumably causes the same 
> problems the new Stream model was intended
> to fix.
>
> In Target\TargetInstrInfo.h
>
>   virtual const TargetRegisterClass *getPointerRegClass() const {
>     assert(0 && "Target didn't implement getPointerRegClass!");
>     abort();
>   }
>
> causes an error (non void funcs must return a value). Add return(NULL) 
> to fix.
>
> Other than that, the MSVC projects reference a few old (deleted) 
> files, but no more code changes are necessary.
>
> Thanks,
> David Shipman
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   




More information about the llvm-dev mailing list