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).
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20061215/ca4db4ff/attachment.html>
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.Okay.> > 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
On 12/14/06, David Shipman <dshipman at gmail.com> wrote:> > 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.We wouldn't accept the patch unless you could get rid of the iostream #include. What are the errors you're seeing? -bw
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 >