If we're keeping the state locally now, perhaps we should store it in a per-thread variable.  I know rand() isn't thread safe to begin with, but it seems like rand_r() can be since it should keep no external state.<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <span dir="ltr"><<a href="mailto:dmitry@kernelgen.org" target="_blank">dmitry@kernelgen.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br><br>In our LLVM-based compiler pipeline a major part of code generation is taken into application runtime. One side-effect of this organization is a need to be very careful about using code that might diverge application state. And we found that simple generation of temporary files over LLVM APIs introduces random noise into the program result. There reason is that LLVM's GetRandomNumber call uses rand(), that clashes with rand() used in application. Taking in account that many client applications developers may be not aware of this at all [and just complain to us, that our compiler is bad because their program is now wrong], we propose switching to self- state maintaining rand() on LLVM side. Attached patch simply replaces the calls to srand() and rand() with a call to rand_r(), which uses static unsigned x value to keep its state locally.<br>

<br>Best,<br>- D.<br>
<br>_______________________________________________<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></blockquote></div><br><br clear="all"><br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</div>