search for: randomnumbergenerator

I searched source code of LLVM/Clang 4.0.0 for 'random_seed' with grep. It seems the -frandom-seed option is not supported. The -rng-seed option appears to be defined in ./lib/Support/RandomNumberGenerator.cpp, which is source code for class RandomNumberGenerator. The constructor of class RandomNumberGenerator is private and is only called by Module::createRNG (defined in lib/IR/Module.cpp). But Module::createRNG does not seem to be called anywhere, except by a unit test. I also tried adding a li...

...defined to be non-deterministic, and you needn't provide methods that you don't call (entropy()) but it would be convenient for everyone reading the API if it were a subset of an existing standard, or with clearly documented deviations from the standard. --- /dev/null +++ b/lib/Support/RandomNumberGenerator.cpp @@ -0,0 +1,271 @@ + +// +// The LLVM Compiler Infrastructure Whoops! Missed the ruler comment at the top. +namespace { + static cl::opt<unsigned long long> + RandomSeed("rng-seed", cl::value_desc("seed"), + cl::desc("Seed for th...

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. - Is diversity needed, or are existing protections sufficient? As

...\andy\llvm+clang-6.0.0rc2-win64-msvc-release\bin\llvm-config.exe" --system-libs psapi.lib shell32.lib ole32.lib uuid.lib But then when I link against LLVM and these libs, I get: lld: error: LLVMSupport.lib(Process.obj): undefined symbol: __imp_CryptAcquireContextW lld: error: LLVMSupport.lib(RandomNumberGenerator.obj): undefined symbol: __imp_CryptAcquireContextW lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegCloseKey lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegOpenKeyExA lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegGetValueW It seems...

Hi, there, I am working on a project on software control flow checking, which instruments a program to check if the control flow at runtime matches the control flow graph computed at compile-time. My instrumentation process has to make use of control flow information, including as control flow graph and dominator/post-dominator trees, so it is better part of the compiler. On the other

...he generic shuffle method. Even using operator() makes the client code particularly unreadable, since it currently uses a static Generator() getter to get the instance of the RNG. I'd like to resolve this first, then we can look at whether using the operator() interface makes sense. > +void RandomNumberGenerator::ReadStateFile(StringRef StateFilename) { > > There's nothing wrong with this function per se. It isn't buggy. I'm just wondering how this API fits with the general "llvm as a library" approach. LLVM doesn't generally bake in the assumption that it's running on...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...gt; Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > Options.h > Parallel.h > Path.h > PointerLikeTypeTraits.h > PrettyStackTrace.h > Printable.h > Process.h > Program.h > RandomNumberGenerator.h > raw_os_ostream.h > raw_ostream.h > raw_sha1_ostream.h > Recycler.h > RecyclingAllocator.h > Regex.h > RWMutex.h > SaveAndRestore.h > ScaledNumber.h > SHA1.h > Signals.h > StringPool.h > StringSaver.h > SwapByteOrder.h > SystemUtils.h > thread.h &g...

...w links in > llvm/lib that are now broken: > > [davide at cupiditate lib]$ grep -R 'llvm.org\/bugs' * > Analysis/ValueTracking.cpp: // https://llvm.org/bugs/show_bug.cgi?id=31702. > Analysis/ValueTracking.cpp: // https://llvm.org/bugs/show_bug.cgi?id=31702. > Support/RandomNumberGenerator.cpp:// http://llvm.org/bugs/show_bug.cgi?id=19665 > Target/AVR/README.md:* [Unresolved > bugs](https://llvm.org/bugs/buglist.cgi?product=libraries&component=Backend%3A%20AVR&resolution=---&list_id=109466) > Transforms/Utils/SimplifyCFG.cpp: // the line - see > https://llvm....

...gt; Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > Options.h > Parallel.h > Path.h > PointerLikeTypeTraits.h > PrettyStackTrace.h > Printable.h > Process.h > Program.h > RandomNumberGenerator.h > raw_os_ostream.h > raw_ostream.h > raw_sha1_ostream.h > Recycler.h > RecyclingAllocator.h > Regex.h > RWMutex.h > SaveAndRestore.h > ScaledNumber.h > SHA1.h > Signals.h > StringPool.h > StringSaver.h > SwapByteOrder.h > SystemUtils.h > thread.h &g...

On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 9 Feb 2018, at 22:30, Dimitry Andric <dimitry at andric.com> wrote: >> >> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <openmp-dev at lists.llvm.org> wrote: >>> >>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org>

....cpp.o CMakeFiles/LLVMSupport.dir/MemoryBuffer.cpp.o CMakeFiles/LLVMSupport.dir/MemoryObject.cpp.o CMakeFiles/LLVMSupport.dir/MD5.cpp.o CMakeFiles/LLVMSupport.dir/Options.cpp.o CMakeFiles/LLVMSupport.dir/PluginLoader.cpp.o CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o CMakeFiles/LLVMSupport.dir/RandomNumberGenerator.cpp.o CMakeFiles/LLVMSupport.dir/Regex.cpp.o CMakeFiles/LLVMSupport.dir/ScaledNumber.cpp.o CMakeFiles/LLVMSupport.dir/ScopedPrinter.cpp.o CMakeFiles/LLVMSupport.dir/SHA1.cpp.o CMakeFiles/LLVMSupport.dir/SmallPtrSet.cpp.o CMakeFiles/LLVMSupport.dir/SmallVector.cpp.o CMakeFiles/LLVMSupport.dir/Source...

LLVMers, We have completed the move to the new server for LLVM.org. One casualty of this move was that svn.llvm.org was NOT enabled at this time. There is a new certificate for LLVM.org and HTTPS is enabled for the website. We know of a few issues with some of the webpages but will be working them out over the next few days. Please do not hesitate to contact llvm-admin at lists.llvm.org with

On 9 Feb 2018, at 22:30, Dimitry Andric <dimitry at andric.com> wrote: > > On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <openmp-dev at lists.llvm.org> wrote: >> >> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org> wrote: >>> >>>> On 9 Feb 2018, at 10:20, Hans Wennborg <hans at chromium.org>

Hallo all, I was trying to Build LLVM with the cmake option LLVM_ENABLE_MODULES just out of curiosity. I used the RELEASE_400/final tag. It didn't work as I almost expected. So I'm wondering if the modulemaps aren't maintained anymore? If they aren't maintained anymore, why aren't they removed and that cmake option also removed?

...PluginLoader.cpp for Release+Asserts build llvm[1]: Compiling PrettyStackTrace.cpp for Release+Asserts build llvm[1]: Compiling Process.cpp for Release+Asserts build llvm[1]: Compiling Program.cpp for Release+Asserts build llvm[1]: Compiling RWMutex.cpp for Release+Asserts build llvm[1]: Compiling RandomNumberGenerator.cpp for Release+Asserts build llvm[1]: Compiling Regex.cpp for Release+Asserts build llvm[1]: Compiling ScaledNumber.cpp for Release+Asserts build llvm[1]: Compiling SearchForAddressOfSpecialSymbol.cpp for Release+Asserts build llvm[1]: Compiling Signals.cpp for Release+Asserts build llvm[1]: Compi...