Disable futures for cygwin

Cygwin testing takes a while and it doesn't seem to be much benefit of running
futures on cygwin.
Disable --gdb execopt on darwin.

Darwin now supports only lldb, so we would have to make the behavior
of the --gdb option platform-dependent.  (That is, start lldb if
running on darwin.)

Separate tests would probably be needed for this option, so just
not testing it on darwin for now.
Modify declint2.prediff to remove leading ./ from gdb output of PGI debug data.
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.
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).
Merge pull request #720 from lydia-duncan/tooManyThreadsForValgrind

Brad pointed out that this should skip with valgrind EXE, not COMP
Quiet align.chpl errors with Intel and PGI compilers.

The odd behavior on Intel and PGI compilers was due to how a 32-bit temporary was being
inlined:
 - On GCC, the declared size of the temporary (int32_t) was being obeyed, either by being
    written back to a 32-bit memory location, or by being sign-extended inline.
 - On Intel and PGI, the 32-bit result was stored in a 64-bit register and not 32-bit
    sign-extended.

The intent of the test was to demonstrate correct behavior with the first 64-bit integer
not representable as a 32-bit integer.  To avoid compiler dependencies, this constant is
now hard-coded.

The compiler-dependent behavior is captured in a new future with a suggestion for
specifying the behavior that is expected.
Add missing EOL on constOverflow.skipif
Reserving various symbols that appear in darwin
Quiet execflags/bradc/gdbddash/declint2 output on PrgEnv-pgi

The existing prediff script looks for "gdbShouldBreakHere" but in the fast tests, GDB
doesn't print it out at all.

Under PGI, the breakpoint location is printed out with a leading dot-slash.

I solved both problems by modifying the prediff to look for the runtime output
  declint2.chpl:7: error: halt reached - array index out of bounds: (0)
instead.

Since the point of the test is to show that we can run under GDB, if we get as far as
generating error output, we have run the program.  Done.
Merge pull request #722 from benharsh/reserve-darwin

Reserving various symbols that appear on darwin

This patch should fix the darwin compilation errors for compSampler*. 'fls' is the name of a function in darwin, and should become a reserved word in Chapel to avoid compilation errors.

These changes should also fix parallel/sync/diten/userLevelEndCount . The 'wait' function can conflict with darwin functions (wait2/3/4) during C compilation.
Modifications in response to Brad's review.

Use max(int(32)):int(64) + 1 in place of a literal constant.

Removed the "Chapel should ..." phrase.

Added detail to the future, to suggest that runtime overflow checking could be on by
default in debug mode and off by default when optimizations are enabled.