[LLVMdev] Interactions between LLVM and the Microsoft C++ runtime

Chris Lattner clattner at apple.com
Tue Jan 20 22:20:41 PST 2009


On Jan 20, 2009, at 1:41 PM, Tim Foley wrote:

> Hello! I am trying to use LLVM 2.4 in a project built with MS Visual  
> Studio 2008. I've been building LLVM with the llvm/win32/llvm.sln  
> solution successfully for x86 and x64. I haven't yet tried to move  
> to the CMake build process, so I'd be interested to hear if the  
> following issues have been resolved on that path.
>
> The problem that I've run into is that the LLVM codebase does  
> certain "idiomatic" things with STL containers that cause assertion  
> failures in the Microsoft runtime. Most notably:
> - Taking the address of the "first element" of an emtpy vector  
> (either &v[0] or &*v.begin())
> - Using an iterator into a collection (even if just for iterator  
> comparison) after an erase() or similar on that collection has  
> invalidated all iterators
> These assertions can occur in both debug and release configurations  
> (Microsoft includes certain assertions in the release runtime for  
> "security").
>
> I do *not* want to start a flamewar on the subject of who is right  
> in this conflict. The Microsoft STL simply assert-fails on things  
> that are officially undefined in the spec for the STL (as a matter  
> of policy), and LLVM just relies on certain pieces of undefined  
> behavior that are typically benign in most implementations.
>
> I'd be interested to hear if other LLVM users have seen these  
> problems or if any have solutions to propose. I have a few possible  
> solutions in mind, but will refrain from going into any of them  
> until I've heard from the community.

hi Tim,

No flame war: llvm should not make non-portable assumptions about the  
STL and windows support is very important for us.  Fortunately, I  
believe all of these issues are fixed on mainline.  The LLVM 2.5  
release branch will be made very soon now, I'd appreciate it if you  
could test mainline and let us know if you hit any problems.

-Chris



More information about the llvm-dev mailing list