llvm dev - Jan 2009 - [LLVMdev] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090120/c797ebe1/attachment.html>

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

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.