Truncate norms and Fvals and update .good files.
Merge branch 'quietMadchap' of https://github.com/chapel-lang/chapel into quietMadchap
Remove redundant truncation of fval and update test_diff.good.
Add suppressions for valgrind's "Unrecognised instruction" failures.
Merge pull request #754 from hildeth/quietMadchap

Quiet madchap floating-point precision diffs on cygwin.

Numerical accuracy differences across platforms are not entirely surprising. It can depend on numerical library implementation choices as well as compiler heuristics (such as FPU register allocation). Running these all down and getting the same exact answer on all machines (especially across different compilers/runtime libraries) could be very time-consuming.

The strategy adopted here was to just print out a fixed number of digits. I also replaced quantities that printed out as "negative zero" with a positive zero, so that small fluctuations around zero do not produce a discernable difference in the output. The .good files were updated accordingly. This eliminates the apparent differences between the cygwin and linux outputs, while still displaying enough digits to allow detection of a serious computational error.

In particular, the internal FP regsiters on ia processors use 80 bits for the intermediate representation, so one can get different results depending on whether intermediate results remain in registers vs. being written back out to memory (as a 64-bit FP rep).  It would be silly to dumb down the results we obtain on linux64 to match the apparently less accurate results on cygwin, so trying to fix this in the backend compiler e.g. by throwing -ffloat-store makes little sense.  The strategy I adopted was to just truncate the printed results so we don't show enough significant digits to display the ones that vary.  I used a hard threshold at 1e-8, which is a zeroeth-order approximation of the numerical accuracy (and a very loose bound).  It will still fail to filter out variations in very large numbers.  But I tested this patch on linux64 as well as cygwin, so it seems like the epsilon (== 1e-8 absolute) is good enough.
Merge pull request #768 from vasslitvinov/suppress-valgrind-Unrecognised-instruction-failures

Add suppressions for valgrind's "Unrecognised instruction" failures.

Summary: these are valid "lock xadd" instructions,
valgrind handles them as of 3.9.0, whereas we are running 3.8.1.

DETAILS

types/atomic/ferguson/atomictest
  unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x89 0xD0 0x5D 0xC3
types/atomic/sungeun/atomic_vars
  unhandled instruction bytes: 0xF0 0xF 0xC0 0xA 0x89 0xCE 0x1 0xF0

valgrind bug
  https://bugs.kde.org/show_bug.cgi?id=307106
valgrind release notes quoting this bug
  http://lwn.net/Articles/572790/

CREDITS
  Greg for taking the lead and decoding the instruction bytes
  Lydia for agreeing with the idea of adding these tests to suppressions