search for: __time__

...rk and so the google guys are usually on top of any issues in this respect (thanks google guys!). > I know it is supposed to be. Does anyone have any data to show this is > going to be an effective approach? It seems like there are benchmarks in > the test-suite which use __DATE__ and __TIME__ in them. I assume that will > be a problem? > __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the OS...

...g strategy to work and so the google guys are usually on top of any issues in this respect (thanks google guys!). I know it is supposed to be. Does anyone have any data to show this is going to be an effective approach? It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem? __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the OS level)....

On 20 May 2015 at 23:31, Sean Silva <chisophugis at gmail.com> wrote: > In the last 10,000 revisions of LLVM+Clang, only 10 revisions actually > caused the binary of MultiSource/Benchmarks/BitBench/five11 to change. So if > just store a hash of the binary in the database, we should be able to pool > all samples we have collected while the binary is the the same as it >

...guys are usually on top of any > issues in this respect (thanks google guys!). > > I know it is supposed to be. Does anyone have any data to show > this is going to be an effective approach? It seems like there > are benchmarks in the test-suite which use __DATE__ and __TIME__ > in them. I assume that will be a problem? > > __DATE__ and __TIME__ should be easy to solve by modifying the > benchmark, or teaching clang to always return a fixed value for them > (maybe we already have this? IIRC google's build system does something > like this; or...

...g strategy to work and so the google guys are usually on top of any issues in this respect (thanks google guys!). I know it is supposed to be. Does anyone have any data to show this is going to be an effective approach? It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem? __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the OS level)....

...google guys are usually on top of any issues in this respect (thanks google guys!). >> >> >> I know it is supposed to be. Does anyone have any data to show this is going to be an effective approach? It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem? >> >> __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it...

...k and so the google guys are usually on top of any issues in this respect (thanks google guys!). > > > I know it is supposed to be. Does anyone have any data to show this is going to be an effective approach? It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem? > > __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the O...

...k and so the google guys are usually on top of any issues in this respect (thanks google guys!). > > > I know it is supposed to be. Does anyone have any data to show this is going to be an effective approach? It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem? > > __DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the O...

...diligence is necessary. Is clang *really* that deterministic, > especially over successive revs? I know it is supposed to be. Does > anyone have any data to show this is going to be an effective approach? > It seems like there are benchmarks in the test-suite which use __DATE__ > and __TIME__ in them. I assume that will be a problem? > > > On May 21, 2015, at 1:43 AM, Renato Golin <renato.golin at linaro.org> > wrote: > > > > On 20 May 2015 at 23:31, Sean Silva <chisophugis at gmail.com> wrote: > >> In the last 10,000 revisions of LLVM+Clang...

On 08/28/2013 12:01 PM, Stephen Checkoway wrote: > 2. Local attacker who cannot read the contents of the binary. (This is a pretty strange one, but it's possible.) The attacker is forced to rely on side channel information such as timing channels in an attempt to discover the length of the inserted NOP sleds. This sounds like an extraordinarily difficult task, but possibly doable. With a

We have NFS mounted drives. I first build an clang/llvm hosted compiler for Mips linux using the clang/llvm linux x86 compiler. Call this clang1. then in directory recurse on Mips host, I place this clang1 compiler and build clang2. then i rename recurse to recurse1 and create a new recurse directory. in recurse I copy clang2 from recurse1 to a recurse but name it clang1. then i build

On Aug 28, 2013, at 1:50 PM, Paul Robinson <pogo.work at gmail.com> wrote: > On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > >> Personally, I think it is necessary to go for the strongest random number >> generator possible. Cryptographically secure pseudorandom number >> generators have good properties that make them

Hi folks, I think we need to update compat5x binary to fix FreeBSD-SA-05:21.openssl, but will the binaries built by ``make universe'' be identical with actual build on Alpha, Sparc64, etc? (Yes, I'm volunteering to do the work iff they are identical ;-) Cheers, -- Xin LI <delphij frontfree net> http://www.delphij.net/ See complete headers for GPG key and other information.