[LLVMdev] Patch to compile LLVM with MSVC 2010

Sergiy Migdalskiy migdalskiy at hotmail.com
Thu Apr 18 00:27:47 PDT 2013


>From the DeveloperPolicy.html document I gathered I need to send a patch to this list (which I did); could you clarify if I misunderstood it?
The second patch is really trivial and I think it's worth applying - it seems like a typo by someone who tested on MSVC 11 but not 10; or maybe my local instance of MSVC10 is somehow deficient, of course.
The first patch is adding MSVC-specific __declspec(noinline) - that's the whole patch - so if someone experienced who has access to all the platforms LLVM compiles on could test it (and/or replace it with something cross-platform; or #ifdef it out everywhere non-MS), I think that would be worth applying to the trunk. I don't have those resources.

The cause of ICE is pretty much right here - inlining utostr crashes MSVC cl.exe. I read about it a few months ago elsewhere and I think the bug was filed with MS (I'm not positive and I have no idea how/where to check it). I don't think I can find much more precise cause within reasonable time, ICE doesn't reproduce in simple cases and I'm not committed enough to do a lengthy binary search of the combination of factors that causes this particular ICE when I only have a lukewarm hope MS would ever give this bug a look. 
Either way, I thought I'd try to push this through. It's not high-value enough to try harder, but it'd be great if someone could help me submit it - it's a really simple couple of patches that make LLVM/clang compile on MSVC10 without further modifications.
Regards,Sergiy

> Date: Wed, 17 Apr 2013 21:56:43 -0700
> Subject: Re: [LLVMdev] Patch to compile LLVM with MSVC 2010
> From: dblaikie at gmail.com
> To: migdalskiy at hotmail.com
> CC: llvmdev at cs.uiuc.edu
> 
> On Wed, Apr 17, 2013 at 11:36 AM, Sergiy Migdalskiy
> <migdalskiy at hotmail.com> wrote:
> > In order to get llvm to compile on Windows with MSVC 10, I have to disable
> > inline on utostr to avoid internal compiler failure, and disable _xgetbv
> > call in OsSupportsAVX because it's only defined in MSVC 2012 compiler. The
> > first patch (noinline) is known for many months now. I'm a casual llvm user,
> > and don't know the proper channels to go through to submit a patch. Could
> > someone tell me, where do I submit patches like this one below?
> 
> http://llvm.org/docs/DeveloperPolicy.html
> 
> > Or maybe why
> > I shouldn't try to do it.
> 
> We're generally happy to apply patches to ensure LLVM compiles on
> relevant compilers. For ICEs it might help to know what the precise
> problem is & to have a bug filed on the compiler.
> 
> >
> > Sincerely,
> > Sergiy
> >
> > Index: include/llvm/ADT/StringExtras.h
> > ===================================================================
> > --- include/llvm/ADT/StringExtras.h (revision 179701)
> > +++ include/llvm/ADT/StringExtras.h (working copy)
> > @@ -84,7 +84,7 @@
> >    return std::string(BufPtr, Buffer+11);
> >  }
> >
> > -static inline std::string utostr(uint64_t X, bool isNeg = false) {
> > +static __declspec(noinline) inline std::string utostr(uint64_t X, bool
> > isNeg = false) {
> >    char Buffer[21];
> >    char *BufPtr = Buffer+21;
> >
> > Index: lib/Support/Host.cpp
> > ===================================================================
> > --- lib/Support/Host.cpp (revision 179701)
> > +++ lib/Support/Host.cpp (working copy)
> > @@ -119,7 +119,7 @@
> >    // there is no easy way to conditionally compile based on the assembler
> > used.
> >    int rEAX, rEDX;
> >    __asm__ (".byte 0x0f, 0x01, 0xd0" : "=a" (rEAX), "=d" (rEDX) : "c" (0));
> > -#elif defined(_MSC_FULL_VER) && _MSC_FULL_VER >= 160040219
> > +#elif defined(_MSC_FULL_VER) && _MSC_FULL_VER > 160040219
> >    unsigned long long rEAX = _xgetbv(_XCR_XFEATURE_ENABLED_MASK);
> >  #else
> >    int rEAX = 0; // Ensures we return false
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130418/c72ffe8c/attachment.html>


More information about the llvm-dev mailing list