search for: miscomputes

On Thu, Oct 6, 2016 at 5:02 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Abe, > > My 2 cents: > I have been using the test-suite mainly in benchmarking mode as a convenient > way to track performance changes in top-of-trunk. > I've observed that some of the programs (IIRC, especially the ones in > SingleSource/Benchmarks/Polybench/) produce

Dear all, Today I had an idea that might satisfy all the needs for improvement we currently have "on the plate" WRT the repo.-wise sizes of reference outputs and the issues surrounding FP optimizations and how to allow them while still allowing test programs in "test-suite" the output[s] of which depend upon FP computations [and for which relatively-small changes in FP

Hey folks, I am not sure who owns bugpoint, but twice now we have had to apply this patch manual. I don’t have commit access, so, help submitting this would be awesome. -------------- next part -------------- A non-text attachment was scrubbed... Name: bugpoint.git.patch Type: application/octet-stream Size: 507 bytes Desc: not available URL:

I'm trying to get R running on AIX 5.1 with the native AIX compilers, VisualAge C++ 5.0.2.0 and XL Fortran Compiler 7.1.0.0. R compiled fine, but in running the test cases, the base-Ex.R tests fail in the Choleski decomposition with the following: > x <- matrix(c(1:5, (1:5)^2), 5, 2) > m <- crossprod(x) > Q <- chol(m) Error in chol(m) : NA/NaN/Inf in foreign function call

...d matching. After some searching, I tracked the issue down to nft_hash_key and nft_hash_lookup_fast - with v0.8, the kernel started preferring hashes instead of bitsets. nft_hash_lookup_fast uses jhash_1word, which always uses the hash initializer appropriate for keys of length == 4. This means it miscomputes the bucket location for 2-byte keys and the lookup fails. In addition, lookups for 4-byte keys will probably fail on big endian machines - the byte-wise jhash used everywhere else reads the u32s as litle endian. I tried removing the fast version of the hash lookups, and it indeed fixes the issue....

Hi! Today I encountered data corruption on two zfs pools due to a RAM failure in my OI box running on a dell T710. My rpool now looks like this (after reboot): pool: rpool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-07:05.libarchive Security Advisory The FreeBSD Project Topic: Errors handling corrupt tar files in libarchive(3) Category: core Module: libarchive

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-07:05.libarchive Security Advisory The FreeBSD Project Topic: Errors handling corrupt tar files in libarchive(3) Category: core Module: libarchive

Hi all, I've only now noticed that on our Opteron boxes running Suse Enterprise Server 8 that R-2.0.1 did not pass make chek-all. It bombed in tests/lapack.R at: > eigenok <- function(A, E, Eps = 1000 * .Machine$double.eps) { V <- E$vect lam <- E$values stopifnot(abs(A %*% V - V %*% diag(lam)) < Eps, .... [TRUNCATED] > Ceigenok <- function(A, E, Eps =