Increase number of trials, but lower amount of work per trial. Compile with --fast
Lowering number of trials for timeout purposes. Lowering iters to avoid timeouts
Some late additions to the regressions file based on late Friday runs

Jenkins went off the rails over the weekend, so no new cron mailings
from there to add.
Merge branch 'master' of https://github.com/chapel-lang/chapel into triage-sep-blc
Updating REGRESSIONS based on this morning's returns
Add lm-numa.good files for some reduction comm count tests

These three tests that count communication for reductions have lower get and
fork counts when run with numa vs. flat.  Added numa specific .good files for
them.
Update to REGRESSIONS based on lasst night's runs
One more... no-local testing just came in
Quiet mismatch with no-use-record.bad due to #678.
Merge pull request #698 from hildeth/master

Quiet mismatch with no-use-record.bad due to #678.
Update GET counts in output to reflect r23004.

As a result of (svn) r23004, the GET counts changed from 36 to 39, for
the Dom1D subtest of the alloc test when the distribution is cyclic.
The test has been in regression ever since.  r23004 made the current
task count more accurate by updating it in a more timely way with
respect to the beginnings and endings of the parallel constructs in a
program.  Since the task count is used to throttle forall parallelism
with dataParIgnoreRunningTasks=false (the default), in some cases this
changed the number of tasks used for a forall-stmt.  In the particular
case of this test I've now concluded that the new counts are due to this
effect and are correct.  r23004 caused the number of tasks to change
from 3 to 4, for an internal forall-stmt at ChapelArrays.chpl:1805
invoked indirectly from what is now line 288 of DefaultRectangular.chpl
(was line 266 at the time of r23004).  Managing more tasks for the loop
increased the remote GET count.  This commit updates the GET counts from
36 to 39 to reflect this.

Note that this test still fails.  Some subsequent change caused the FORK
counts for all the subtests to decrease by 6, but this was not noticed
because the test was already failing due to the GET mismatch.  I'll
figure out the FORK change separately.
Merge pull request #699 from bradcray/triage-sep-blc

Triage update after first two days of "regressions week"

New regressions
---------------

* a bunch of lulesh out-of-bound failures on prgenv-cray for unknown
  reasons (hilde investigating, thanks Tom!)

* .bad mistmatch for no-use-record due to improved behavior now
  (hilde updated .bad -- should be fixed on next run)


Improvements
------------

* one gdbddash tests passing on darwin now, though three remain
  (thanks hilde!)

* parSafeAdd retired for valgrind testing, though still failing under
  gasnet-fast (thanks Ben!)

* record_from_string .bad mismatch now passing in most configurations
  other than xe-wb.*, just due to normal testing lag (thanks hilde!)

* testProbSize, countMemory now working for darwin (thanks me!)

* refArgIsWide now passing for darwin (thanks Kyle!)

* io/sungeun/ioerror now passing on darwin (thanks hilde!)

* time-sync-incs and hplExample5 now passing on darwin (thanks Kyle!)

* remoteStringTuple now passing for gasnet (thanks Kyle!)

* hpl and fft variants no longer getting double free or corruption under
  baseline testing (thanks Mike!)

* inlfunc*_report no longer complaining about missing suppression under
  baseline (thanks me!)

* cyclic communication counts now working for assign and reduce (thanks
  Vass!)


Misc
----
* moved some nbody_* tests to the sporadic category because they are

* ditto some sporadic cyclic failures

* added some new dates to sporadic failures
Allow mallOutOfMemory to complete with gasnet+fast

This test was setting virtual memory low in an attempt to get the test to
complete quickly.  Gasnet+fast seems to need more memory to work at all, though,
so bump the limit.
Merge pull request #697 from daviditen/fixNumaCommCounts

Add lm-numa.good files for some reduction comm count tests

These three tests that count communication for reductions have lower get and
fork counts when run with numa vs. flat. Added numa specific .good files for
them.
More tasks, slightly fewer trials
Merge pull request #700 from gbtitus/r23004-alloc-cyclic

Update GET counts in output to reflect r23004.

As a result of (svn) r23004, the GET counts changed from 36 to 39, for
the Dom1D subtest of the alloc test when the distribution is cyclic.
The test has been in regression ever since. r23004 made the current
task count more accurate by updating it in a more timely way with
respect to the beginnings and endings of the parallel constructs in a
program. Since the task count is used to throttle forall parallelism
with dataParIgnoreRunningTasks=false (the default), in some cases this
changed the number of tasks used for a forall-stmt. In the particular
case of this test I've now concluded that the new counts are due to this
effect and are correct. r23004 caused the number of tasks to change
from 3 to 4, for an internal forall-stmt at ChapelArrays.chpl:1805
invoked indirectly from what is now line 288 of DefaultRectangular.chpl
(was line 266 at the time of r23004). Managing more tasks for the loop
increased the remote GET count. This commit updates the GET counts from
36 to 39 to reflect this.

Note that this test still fails. Some subsequent change caused the FORK
counts for all the subtests to decrease by 6, but this was not noticed
because the test was already failing due to the GET mismatch. I'll
figure out the FORK change separately.

[Reviewed by hildeth.]
Remove futures passing due to #678.
Merge pull request #682 from benharsh/parsafe-fix

The motivation for this patch is to stop this test from periodically failing under certain configurations.

This inner loop has been rewritten to improve clarity. A 'trials' config var has been added to provide more flexibility when tuning the problem size. A verification step has also been added which ought to catch glaring issues.

Previously we were choosing a range based on the condition "n & 1". I believe this test would be more valuable if the condition was instead "t & 1", which varies the range (ascending/descending) based on the current task.

The overall problem size has been reduced significantly to avoid timeouts. Compiling with --fast should be more useful when attempting to stress the test and expose a race condition, while also reducing the chance for timeouts.
Turn off mallocOutOfMemory for darwin, as it does not behave appropriately

This test depends on the ability to limit the amount of virtual memory so that
the process will attempt to allocate too much and exit with an error message.
Unfortunately, various internet sources tell me that Darwin's ways to limit
virtual memory do not work.  Since the alternative is a test that would stomp
all over everything if left unchecked and that will always time out in our
testing system, I'm turning it off for darwin.
Merge pull request #702 from lydia-duncan/fixOutOfMemory

Fix mallocOutOfMemory test

This test was failing on gasnet+fast and darwin. On gasnet+fast, the
virtual memory limit placed upon the test was too low to allow Chapel
to actually do anything, so it was timing out. On darwin, the virtual
memory limit was not respected (because according to internet
sources ulimit and setrlimit do not work on OSX), so the test would
never perform as expected. To resolve the former, I increased the
virtual memory size. To resolve the latter, I turned off this test for
darwin.