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 (I'm on FreeBSD). I ran strings(1) on the two clang binaries, and I get the following: >> 251862c251862 >> < N4llvm3sys11ThreadLocalIKN144_GLOBAL__N__usr_home_erik_freebsd_head_src_lib_clang_libllvmsupport_.._.._.._contrib_llvm_lib_Support_CrashRecoveryContext.cpp_00000000_BFDB511124CrashRecoveryContextImplEEE >> --- >>> N4llvm3sys11ThreadLocalIKN144_GLOBAL__N__usr_home_erik_freebsd_head_src_lib_clang_libllvmsupport_.._.._.._contrib_llvm_lib_Support_CrashRecoveryContext.cpp_00000000_A7307A7424CrashRecoveryContextImplEEE >> > Urgh, are we using random elements in the unnamed namespace symbol > generation? > > Sebastian > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 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 (I'm on FreeBSD). I ran strings(1) on the two clang binaries, and I get the following: >>> 251862c251862 >>> < N4llvm3sys11ThreadLocalIKN144_GLOBAL__N__usr_home_erik_freebsd_head_src_lib_clang_libllvmsupport_.._.._.._contrib_llvm_lib_Support_CrashRecoveryContext.cpp_00000000_BFDB511124CrashRecoveryContextImplEEE >>> --- >>>> N4llvm3sys11ThreadLocalIKN144_GLOBAL__N__usr_home_erik_freebsd_head_src_lib_clang_libllvmsupport_.._.._.._contrib_llvm_lib_Support_CrashRecoveryContext.cpp_00000000_A7307A7424CrashRecoveryContextImplEEE >>> >> Urgh, are we using random elements in the unnamed namespace symbol >> generation? >> >> Sebastian >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 12 November 2010 12:48, Chris Lattner <clattner at apple.com> wrote:> 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.One thing I have seen done with gcc is "gcc -c foo.c -o foo.o -frandom-seed=foo.o". That way you still get a different seed for different output files.> -ChrisCheers, Rafael
Den 12/11/2010 kl. 18.48 skrev Chris Lattner:> 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.I'll try that. I assume that the randomness has a purpose, so what are the negative implications of setting -frandom-seed=0? Will i still have a functioning compiler? :-) Thanks, Erik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1928 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101114/2c4b8882/attachment.bin>