search for: rand_r

Agreed, done. One thing I'm not sure about is this statement in docs: POSIX.1-2008 marks *rand_r*() as obsolete. - And... what is the replacement? 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > 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 li...

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. On Sat, Dec 1, 2012 at 11:17 AM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > Dear all, > > In our LLVM-based compiler pipeline a major part of code generation is > taken into application runtime. One side-effect of this org...

Correcting my patch, reg. __thread stuff I'm not very familiar with. - D. 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > Agreed, done. > > One thing I'm not sure about is this statement in docs: > > POSIX.1-2008 marks *rand_r*() as obsolete. > > - And... what is the replacement? > > > 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> > >> 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...

...y 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. Best, - D. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121201/ffc5d28b/attachment.html> -------------- next part -------------- A non-t...

...cting my patch, reg. __thread stuff I'm not very familiar with. > > - D. > > > 2012/12/1 Dmitry Mikushin <dmitry at kernelgen.org> > >> Agreed, done. >> >> One thing I'm not sure about is this statement in docs: >> >> POSIX.1-2008 marks *rand_r*() as obsolete. >> >> - And... what is the replacement? >> >> >> 2012/12/1 Justin Holewinski <justin.holewinski at gmail.com> >> >>> If we're keeping the state locally now, perhaps we should store it in a >>> per-thread variable. I kn...

...to the Asterisk systems. I have been doing a lot of research into this problem. I found this bug tracker http://bugs.digium.com/view.php?id=5912 that talks about it being an old problem with version 1.2.1 using rand() and it not being thread safe. This I can understand. The thread proposed using rand_r() or ast_random() in place of rand(), that sounds like a good idea. So when I look at my newer 1.2.18 version I find that it is still using rand() and the bug tracker continues to be opened and closed and reopened again and again. Do I dare ask if anyone has a reliable IAX2 trunk? If so how? Shoul...

...the Asterisk systems. I have been doing a lot of research into this problem. I found this bug tracker http://bugs.digium.com/view.php?id=5912 that talks about it being an old problem with version 1.2.1 using rand() and it not being thread safe. This I can understand. The thread proposed using rand_r() or ast_random() in place of rand(), that sounds like a good idea. So when I look at my newer 1.2.18 version I find that it is still using rand() and the bug tracker continues to be opened and closed and reopened again and again. Do I dare ask if anyone has a reliable IAX2 trunk? If so how? S...

Hi everyone, sorry if this has been answered before - I caught a whiff of a discussion about c's rand() function in a mailing list archive, but couldn't find a definitive answer. I'm trying to do a simple CS project on my machine where I generate two sets of values in parallel using rand() and am running into infinite loops of values, and couldn't figure out why, so I wrote a test

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

...iver are relocated too. libport: Replacement for poll(). secur32: Check for lack of fork() support. ws2_32: Added implementation for inet_ntop. rpcrt4: Disable TCP/IP connection support if we don't have socketpair. shell32: Use RtlRandom instead of the non-portable rand_r. include: Add the needed dllimport attribute to the RtlUnwind declaration. gdi32: Fix the build without Freetype LCD support. libport: Avoid including winsock2.h. user32: Fix SPI_SETMOUSESPEED handling, the parameter is not a pointer. server: Store data for hardware me...

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

...setstate_r (char *__restrict __statebuf, struct random_data *__restrict __buf) __attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2))); extern int rand (void) __attribute__ ((__nothrow__)); extern void srand (unsigned int __seed) __attribute__ ((__nothrow__)); extern int rand_r (unsigned int *__seed) __attribute__ ((__nothrow__)); extern double drand48 (void) __attribute__ ((__nothrow__)); extern double erand48 (unsigned short int __xsubi[3]) __attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1))); extern long int lrand48 (void) __attribute__ ((__nothrow__)); exte...