Snapshot of mid-day regressions

This updates REGRESSIONS based on things that came in mid-day and
also contains some mods to REGRESSIONS-stories to try and update
things, though it's muddied a bit by partial returns so far.
Adding in tonight's cygwin results
Avoid variable name shadowing (whoops, typing too fast).
Merge pull request #712 from lydia-duncan/moreOOMFixes

Avoid variable name shadowing (whoops, typing too fast).
Merge branch 'master' of https://github.com/chapel-lang/chapel into triage-sep-blc
Merge branch 'triage-sep-blc' of https://github.com/bradcray/chapel into triage-sep-blc

Conflicts:
	test/REGRESSIONS
Triage update based on this morning's returns
Silencing --baseline regression from last night and adding a future

It seems that using a 'ref' var (currently 'refvar') within an
iterator breaks when the iterator is represented by an object as
this test demonstrates.  When we're not compiling --baseline,
the iterator object is optimized away, so things work fine; with
--baseline, it segfaults.  I'm not 100% sure I'm diagnosing this
properly, but it makes sense and seems to match what I'm seeing
in the generated code.  See the .future file for details.
Merge pull request #713 from bradcray/nbody-regressions-week

Addressing --baseline regression from last night and adding a future

[trivial, not reviewed]

It seems that using a 'ref' var (currently 'refvar') within an
iterator breaks when the iterator is represented by an object, as
this test demonstrates. When we're not compiling --baseline,
the iterator object is optimized away, so things work fine; but with
--baseline, it segfaults. I'm not 100% confident I'm diagnosing this
properly, but it makes sense and seems to match what I'm seeing
in the generated code. See the .future file for details.
Updating valgrind testing based on last night's runs
Updating my tally of stories lists based on recent returns

Note that in some cases, stories may be done but haven't gone
through testing yet.
Updating w.r.t. the no-local tests that just came in
Merge pull request #714 from bradcray/triage-sep-blc

Updating triage based on past 24 hours or so

New regressions
---------------
* c_str_on_remote_string .bad mismatch due to remote string changes (kyle)

* nbody_iterator_7 segfaulting on --baseline (bradc -- should now be fixed)


Improvements
------------
* mallocOutOfMemory fixed for darwin (thanks Lydia!)

* parSafeMember fixed for valgrind (thanks Ben!)

* remoteDynamicDispatch and access?d fixed for gasnet (thanks Kyle!)

* ioerror fixed for cygwin (thanks hilde!)

* countMemory/testProbSize fixed for cygwin (thanks me!)

* barrier timeouts fixed for cygwin (thanks Elliot!)

* test_glob and Leve_DiffusionBE_driver fixed for baseline (thanks Mike!)


Misc
----
* updated notes on yesterday's lulesh OOB error to correlate to hilde's PR #678

* no-use-record .bad mismatch and fix continuing to work its way through testing

* noted new occurrences of sporadic sudoku, lulesh, test_array_slicing3, jacobi
  failures
Fix TooManyThreads valgrind error

This test requires that CHPL_RT_NUM_THREADS_PER_LOCALE is unset for correct
output, but our valgrind testing sets this variable in order to run.  Therefore,
the test is not useful under these circumstances.  The effort to make the
prediff more correctly react to this variable being set seemed much greater than
the payoff, so I left a note in the test of how it could be done and turned it
off for valgrind.
Adjusted the prediff to squash .bad mismatch.
Merge pull request #718 from vasslitvinov/fix-hplx.chpl-prediff

Adjusted the prediff to squash .bad mismatch for hplx.chpl.

For this test:

  test/distributions/dm/hplx.future

the erroneous output can be quite diverse.
I set the prediff - specifically, a case in PREDIFF -
to filter out everything except the correct output
and errors, aiming at a clean match against .bad.

When I did that, I saw "error: attempt to dereference nil"
reported only in ReplicatedDist.chpl, so I filtered
out that error line. Last night we saw that error
reported in ChapelBase.chpl instead. So this change
is to relax the filter to allow that error in any file.
Merge pull request #717 from lydia-duncan/tooManyThreadsForValgrind

Fix TooManyThreads valgrind error

This test requires that CHPL_RT_NUM_THREADS_PER_LOCALE is unset for correct
output, but our valgrind testing sets this variable in order to run. Therefore,
the test is not useful under these circumstances. The effort to make the
prediff more correctly react to this variable being set seemed much greater than
the payoff, so I left a note in the test of how it could be done and turned it
off for valgrind.
Fix a race in studies/jacobi/waynew/example2.chpl

This test had been very rarely generating incorrect output due to failing to
detect that sufficient change had occurred between late passes.  This happened
because the variable used to determine if sufficient change had occurred was
being updated by all running tasks without locking so there was a race.  Since
we don't support atomic |= for booleans, I replaced the boolean with an atomic
integer, and the |= call with atomically adding the old boolean check (so if
the result of comparing the new and old values was above the tolerance for a
change, then an integer representation of true would be added).  After 150 runs,
it appears that this has solved the problem.
Brad pointed out that this should skip with valgrind EXE, not COMP
Merge pull request #719 from lydia-duncan/fixJacobiRace

Fix a race in studies/jacobi/waynew/example2.chpl [suggested by Brad]

This test had been very rarely generating incorrect output due to failing to
detect that sufficient change had occurred between late passes. This happened
because the variable used to determine if sufficient change had occurred was
being updated by all running tasks without locking, so there was a race. Since
we don't support atomic |= for booleans, I replaced the boolean with an atomic
integer, and the |= call with atomically adding the old boolean check (so if
the result of comparing the new and old values was above the tolerance for a
change, then an integer representation of true would be added). After 150 runs,
it appears that this has solved the problem (100 runs was sufficient to see 6
failures in this manner with fifo before this change).