search for: getrandomnumber

...n 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() o...

...untime. 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...

...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 pr...

...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 switch...

...sd/work/svn/lgs/build/lib/Support' llvm[1]: Compiling Process.cpp for Debug+Asserts build In file included from /mnt/ssd/work/svn/lgs/llvm/lib/Support/Process.cpp:103:0: /mnt/ssd/work/svn/lgs/llvm/lib/Support/Unix/Process.inc: In static member function ‘static unsigned int llvm::sys::Process::GetRandomNumber()’: /mnt/ssd/work/svn/lgs/llvm/lib/Support/Unix/Process.inc:368:21: error: ‘arc4random’ was not declared in this scope return arc4random(); ^ /mnt/ssd/work/svn/lgs/llvm/lib/Support/Unix/Process.inc:374:1: warning: control reaches end of non-void function [-Wreturn-type...

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

Hey all, FYI - We're seeing a whole host of errors around requiring arc4random and linkage errors building llvm/clang/lldb from top of tree. This is on lldb builds with Ubuntu 12.04 x86_64, using gcc 4.8.2 and configure-based builds. This appeared to crop up sometime since Friday morning. What's the right fix for that? Looks to be a dependency on libbsd? -- Todd Fiala | Software

...erhead. The patch also removes a FIXME from the set_fixed_execution_seed implementation and rewords the documentation string a bit, since using this function in a multi-threaded program requires some kind of external synchronization anyway. Another attached patch implements llvm::sys::Process::GetRandomNumber() on Windows. (There's already a Unix implementation.) This function could be useful for implementing the missing random per-execution seed functionality. (Though it might take a little care to deal with Process::GetRandomNumberSeed potentially calling back into hash_combine on Unix.) In...

...during the > build which causes a build failure. On the failed builds I usually see > things being linking/compiling twice e.g. ... > and from the above mentioned example the build failed with > > > ../../lib/libLLVMSupport.a(Process.cpp.o): In function > `llvm::sys::Process::GetRandomNumber()': > Process.cpp:(.text._ZN4llvm3sys7Process15GetRandomNumberEv+0x70): > undefined reference to `llvm::sys::TimeValue::now()' > collect2: error: ld returned 1 exit status This looks like something I fixed recently, in r290271: commit 8bddda3652b36619cc8cd916c33d38c9cd41f024...

...lgrind.cpp.o CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o /usr/bin/ranlib ../libLLVMSupport.a /usr/bin/ranlib ../libLLVMSupport.a Sorry for the clutter here... :( and from the above mentioned example the build failed with ../../lib/libLLVMSupport.a(Process.cpp.o): In function `llvm::sys::Process::GetRandomNumber()': Process.cpp:(.text._ZN4llvm3sys7Process15GetRandomNumberEv+0x70): undefined reference to `llvm::sys::TimeValue::now()' collect2: error: ld returned 1 exit status I also see exactly 4 instances of "warning: jobserver unavailable: using -j1. Add `+' to parent make rule."...

Hi, Currently the hashing implementation in ADT/Hashing.h produces hash values on 32-bit platforms that differ from the lower 32-bits of the hash values produced on 64-bit platforms. It seems the only reason for this difference is that the uint64_t integer seed is truncated to size_t. Since the usage of uint64_t and size_t as types for seed values in the implementation is somewhat