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.
Update .good/.prediff for chown file to support cygwin platform.

On cygwin, chown is reporting an "Invalid argument" error instead of the
expected "Operation not permitted" error. The new prediff replaces both
of these with "SYS_ERR", which is what the .good file now expects.
Convert collapseBlocks functions in to methods on FnSymbol and BlockStmt
Update the interface to buildVarDecls for LLVM
Merge pull request #758 from thomasvandoren/cygwin-regressions

Update .good/.prediff for chown file to support cygwin platform.

On cygwin, chown is reporting an "Invalid argument" error instead of the
expected "Operation not permitted" error. The new prediff replaces both
of these with "SYS_ERR", which is what the .good file now expects.
Merge pull request #767 from noakesmichael/collapseBlocks

Initial code shuffle collapse blocks and fix for LLVM

1) There is an operation that collapses nested BlockStmts in appropriate contexts.  The current implementation must be refactored as part of the While/For loop refactoring.  This is an initial trivial code shuffle to convert 
existing function in to AST class methods.  No change in functionality.

2) Also an update to LLVM code to conform to the new interface to buildVarDecls.


Compiled: Clang darwin STD, GCC linux64 STD, GCC linux64 LLVM
Tested: Full regression suite STD and LLVM
Reviewed: None
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.