[LLVMdev] ThisCall / Compilation problems

Reid Spencer rspencer at reidspencer.com
Thu Dec 14 16:46:44 PST 2006

Hi David,

On Fri, 2006-12-15 at 12:59 +1300, David Shipman wrote:
> 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). 

Just run: 
   utils/mkpatch ThisCall

It will produce ThisCall.patch which you can submit to llvm-commits.

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

Yeah, its a bug in MS Visual C++ Express :)

But, we'll take the patch to work around it. Again, just use mkpatch.

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

Yes, it would. We're unlikely to accept that patch. Is there another way
to work around it?

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

We'd welcome the updates to keep things compiling.

> 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