similar to: RFC: Should the default LLVM build be deterministic?

It is with great sadness that I must tell everyone CMake’s Ninja generator is non-deterministic (https://public.kitware.com/Bug/view.php?id=15968 <https://public.kitware.com/Bug/view.php?id=15968>). I’m not sure if this impacts all versions of CMake, but it certainly impacts all the recent releases. You might ask why this matters? Sadly the non-determinism *does* impact determinism in the

In the past, I had added the ability in LLVM to uncover 2 types of non-deterministic behaviors: iteration of unordered containers with pointer-like keys and sorting of elements with the same keys. Now, I wanted to add checkers for these (and other types of non-deterministic behaviors) so that they could be applied more widely. I also realize that not all of these may be doable at

Thanks for your response David. 1) I'm not sure it's do-able. I don't know of any nice way to track whether an ordered walk of an unordered container leaks out into the final output of the program. Only iterating over an unordered container is probably not a sufficient hint (it'd have a high false positive rate to warn on every instance of that) - and I don't have any

Hi all, I am in charge of the controlled introduction of clang into our builds at my workplace. Since all our tools must run from a ClearCase view for automatic dependency tracking, we have been biten by a Linux bug, and readlink("/proc/self/exe", ...) gives nonsensical results. So we need to introduce a configure option for disallowing this method of executable discovery (the other one

On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Hi all, > > I am in charge of the controlled introduction of clang into > our builds at my workplace. Since all our tools must run from > a ClearCase view for automatic dependency tracking, we have been > biten by a Linux bug, and readlink("/proc/self/exe", ...) gives >

Hello, For debugging purposes, I've added a unique id member to the Value class: global_next_vuid = 0; Value::Value(..){ vuid = ++global_next_vuid; } My hope is that by looking at the vuid of a Value, I can see its vuid, set a conditional breakpoint and re-run the compiler to see who (what pass) constructed that value. Maybe I am not doing it the right way, but the above 'vuid'

I am in the middle of the fun and games of updating my out-of-tree sources to the LLVM head revisions, and after updating to CMake v3.5.2 I am now getting a warning that 'ENABLE_TIMESTAMPS' is being ignored. Has support for embedding the timestamp in the build been removed or is there a new way of configuring it? I generally build internal transitional builds with this enabled so that

On Mon, May 18, 2009 at 8:33 PM, dan mihai <dnmh68 at hotmail.com> wrote: > Hello, > Yo! > For debugging purposes, I've added a unique id member to the Value class: > > global_next_vuid = 0; > Value::Value(..){ >   vuid = ++global_next_vuid; > } > > My hope is that by looking at the vuid of a Value, I can see its vuid, > set a conditional breakpoint and

Hi, On Tue, Jun 28, 2016 at 3:25 PM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am in the middle of the fun and games of updating my out-of-tree sources > to the LLVM head revisions, and after updating to CMake v3.5.2 I am now > getting a warning that ‘ENABLE_TIMESTAMPS’ is being ignored. > > > > Has support for embedding the timestamp

Yes, this is controlled by the -frandom-seed flag. Sadly, it is expected behavior. -Chris On Nov 12, 2010, at 7:10 AM, Sebastian Redl <sebastian.redl at getdesigned.at> wrote: > On 12.11.2010 15:26, Erik Cederstrand wrote: >> I have noticed that two consecutive builds of clang, clang++ and tblgen don't produce identical binaries (as in md5 sums) on identical source code

The generated code is deterministic, but the global order the instructions were generated seems it is not (although the result is guaranteed to be the same). Now I think the order functions are processed might not be guaranteed. I've attached a test case, and here is what I get: ............................... (303)$ ~/bin/llvm/bin/gcc -O3 -emit-llvm try_calls_basic.2.c -c -o

Guys, It seems as though the llvm system doesn't deterministically iterate over Module::iterator, or global_iterator. To make myself clearer, the iterators iterate over all the global_variables but on different llvm passes (different calls to opt -load), the iterators iterate over them in different orders. I was thinking that it has something non deterministic to do with byte code reading or

Hi, Recently I want to fuzz samba systematically (instead of functional fuzzing like OSS-Fuzz/samba). However, the fuzzer acts like smbclient and needs to establish a connection with the samba server via NTLM authentication. The NTLMSSP_Challenge sent by the server is not deterministic, which can render the fuzzing based on previously captured traffic futile. Does samba provide a fuzzing mode

Oh, I should point out that using randomness is the unfortunate part, but you can get deterministic builds by passing -frandom-seed=0 to clang and/or gcc. -Chris On Nov 12, 2010, at 9:19 AM, Chris Lattner wrote: > Yes, this is controlled by the -frandom-seed flag. Sadly, it is expected behavior. > > -Chris > > On Nov 12, 2010, at 7:10 AM, Sebastian Redl <sebastian.redl at

I haven't tested it, but it looks to me like llvm-profdata merge (well, InstrProfWriter specifically) would not have deterministic output. Certainly the textual output iterates over FunctionData which is a StringMap of SmallDenseMaps, neither of which has deterministic iteration. The binary writing looks like it'd have similar issues - looping through these unordered maps & writing

On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > > Grang, Mandeep Singh via llvm-dev > > Sent: Thursday, July 06, 2017 2:56 AM > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev]

Forgot cc, the entire group. How can deterministically iterate over the uses of a variable. i.e. the uses should be any particular order that doesn't change from execution to execution of the opt tool. To make myself more clearer, here is a snippet of code that has Values reordered each time I analyze a particular piece of code(which doesn't change) with the LLVM opt tool and my LLVM

Dear guRus, I am starting to work with the ggplot2 package and have two very dumb questions: 1) deterministic position_jitter - the jittering is stochastic; is there any way to get a deterministic jittering? For instance: example.data <- data.frame(group=c("foo","bar","foo","bar","foo","bar"),x=c(1,1,2,2,3,3),y=c(1,1,0,2,1,1))

On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> wrote: > On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> I haven't tested it, but it looks to me like llvm-profdata merge (well, >> InstrProfWriter specifically) would not have deterministic output. >> >> Certainly the textual output iterates

On Thu, Jul 6, 2017 at 12:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jul 6, 2017 at 10:20 AM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>>