Interactions between LLVM and the Microsoft C++ runtime

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.

  • Tim Foley

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

Hi,

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

if you configure with --enable-expensive-checks on linux then I
think all of these are checked. The upcoming 2.5 llvm build is
mostly clean but some issues did come up when building llvm-gcc.
They are being worked on (at least I hope they are!), PR3358.

Ciao,

Duncan.

This is great news. I am pulling down the mainline and will see if this clears things up.

  • Tim