Truncate norms and Fvals and update .good files.
Add .execenv files to set QT_NUM_SHEPHERDS=2 and update .lm-numa.good files

The number of communications depends on the number of shepherds when using the
numa locale model, so force the number of qthreads shepherds to 2.  Update
the .lm-numa.good files to match the comm counts for two shepherds.
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
Retire c_str_on_remote_string as a future, open new related future

The intended functionality of c_str_on_remote_string works correctly,
but the test was still failing due to reasons that have been spun out
into write_c_string.

write_c_string.future:

bug: c_string variables should not be used with write

c_strings are only valid in the locale they were created on. Trying to write
one from a locale other than the channel's home will cause the use of a bad
pointer. We should disallow the use of c_string in our IO system. If users
really want to print one they can cast to string.
Merge pull request #769 from Kyle-B/kb-remote-string-futures

Retire c_str_on_remote_string as a future, open new related future

The intended functionality of c_str_on_remote_string works correctly,
but the test was still failing due to reasons that have been spun out
into write_c_string.

write_c_string.future:

bug: c_string variables should not be used with write

c_strings are only valid in the locale they were created on. Trying to write
one from a locale other than the channel's home will cause the use of a bad
pointer. We should disallow the use of c_string in our IO system. If users
really want to print one they can cast to string.
Merge pull request #752 from daviditen/numaCommCountUpdates

Add .execenv files to set QT_NUM_SHEPHERDS=2 and update .lm-numa.good files
[reviewed by ronawho]

The number of communications depends on the number of shepherds when using the
numa locale model, so force the number of qthreads shepherds to 2. Update
the .lm-numa.good files to match the comm counts for two shepherds.
Updating REGRESSIONS based on past few days' runs
Minor cleanup to REGRESSIONS; update to REGRESSIONS-stories
Updating based on valgrind testing which just came in
Merge pull request #772 from bradcray/triage-sep-blc

Regressions update for the past few days

New regressions
---------------
* missing chpl_memcpy() prototypes (fixed now, still filtering through)

* got a recursive AMUDP_SPMDShutdown error in distributions/dm/hplx (vass)

* got a new suite of tests that get the "array index out of bounds error"
  (while the lulesh ones cleaned themselves up a few days ago) -- I think
  this is the qthreads memory fence issue that greg is looking into.

Improvements
------------
* extern/ferguson/c_ptrs now fixed for Mac (thanks Kyle!)

* overlapping memcpy valgrind issues now fixed (thanks hilde!)

* sungeun/lulesh timeouts resolved (thanks me!)

* leakedmemory5 no longer complaining about lack of suppression (thanks Lydia!)

* valgrind atomic tests silenced (thanks vass!)

* two lammps valgrind timeouts silenced (thanks vass!)

Misc
----
* moved qio_test consistent timeout to sporadic unless someone wants to
  take credit for closing it (I couldn't tell)

* noted new dates for sporadic timeouts