Oh yes you're right, I missed that :) But the point still hold.<br><br clear="all">Amaury Pouly<br>
<br><br><div class="gmail_quote">2010/8/8 Eugene Toder <span dir="ltr"><<a href="mailto:eltoder@gmail.com">eltoder@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">> Not only this code does not compile with NDEBUG set<br>
<br>
</div>I may be missing something, but why does it not compile with -DNDEBUG?<br>
assert() macro expands to noop when NDEBUG is set.<br>
<br>
Eugene<br>
<div><div></div><div class="h5"><br>
On Sun, Aug 8, 2010 at 2:19 PM, Amaury Pouly <<a href="mailto:amaury.pouly@gmail.com">amaury.pouly@gmail.com</a>> wrote:<br>
> Hello,<br>
> I was trying to interface a custom backend instruction scheduler with llvm<br>
> code when I realize something terrible. The scheduling code builds a graph<br>
> made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are<br>
> allocated via a std::vector< SUnit >.<br>
> This isn't a problem as long as the pointers are taken after the vector is<br>
> fully filled and the vector never changes its size. But the problem is that<br>
> is can happen !<br>
> Indeed, in some rare cases, the scheduler needs to duplicate a SUnit and<br>
> thus allocate a new one. This gives code this:<br>
><br>
> ScheduleDAGSNodes.cpp:<br>
><br>
> #ifndef NDEBUG<br>
>   const SUnit *Addr = 0;<br>
>   if (!SUnits.empty())<br>
>     Addr = &SUnits[0];<br>
> #endif<br>
>   SUnits.push_back(SUnit(N, (unsigned)SUnits.size()));<br>
>   assert((Addr == 0 || Addr == &SUnits[0]) &&<br>
><br>
> Not only this code does not compile with NDEBUG set but it could trigger an<br>
> extermely reliable assertion failure in some cases. One could think that<br>
> this is too rare to happen but it does happen with my scheduler and I'm not<br>
> quite embarassed because I can't do anything apart from hacking llvm source<br>
> code. I feel that triggering an assertion failure just because the user made<br>
> the mistake of having not luck is not great for such a big framework as LLVM<br>
> :)<br>
><br>
> Shouldn't LLVM use a custom vector implementation for such cases, an<br>
> implementation that does not invalidate pointers when growing ?<br>
> I have such an implementation at hand that I'm willing to provide if needed.<br>
><br>
> Regards<br>
><br>
><br>
> Amaury Pouly<br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
</blockquote></div><br>