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
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.
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.
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.
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.
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.
Convert scopeless BlockStmt to scoped to fix several --baseline regressions to pass
The change to ForLoop exposed an issue with some cryptic code that quietly drops the last statement in a Zip4 block.  We're not sure why this was done, prior to 2008, but it does not seem to be appropriate today
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.
Update FORK counts for alloc with cyclic due to coerce wrapper change.

Vass's change to remove coercion wrappers (pull request #250) reduced
the comm FORK counts for this test as it did for others, but we didn't
notice that because this test had previously regressed.  Earlier today
I fixed that regression in pull #700, and now I'm fixing the cyclic
.good file for the reduced FORK counts.
Merge pull request #703 from hildeth/master

Remove futures passing due to #678.
Different approach to the mallocOutOfMemory problem: limit the heap size

Also made the test have a set end to its loop as Brad suggested instead of
letting it run to infinity when things don't work right.
Added a future for crash when creating privatized array/domain slices concurrently.
Added a test temp file to .gitignore.
Merge pull request #706 from vasslitvinov/add-future-test-hpl+replicated

Added a future for crash when creating slices of privatized array/domain concurrently.

From .future:

This test crashes intermittently at runtime in the forall loop with -nl4.

The errors I observed in various runs include:
* ReplicatedDist.chpl:272: error: attempt to dereference nil
* Caught a fatal signal: SIGABRT(6) on node 0/4
* *** glibc detected *** hplx_real: corrupted double-linked list: ....
* malloc.c:3091: sYSMALLOc: Assertion `.....' failed.

Uncommenting the commented-out code in the test and/or increasing 'fac'
should increase the probability of failure.

Valgrind detects "Invalid read of size 8", perhaps reliably,
even under -nl2.
In my setup (with fifo) it runs longer than several minutes,
I don't know if it ever terminates.

When this test is fixed, please enable this test for ReplicatedDist
by removing its .skipif:

  test/distributions/robust/arithmetic/kernels/hpl.chpl
Merge pull request #705 from lydia-duncan/fixOutOfMemory

Different approach to the mallocOutOfMemory problem: limit the heap size

Also made the test have a set end to its loop as Brad suggested instead of
letting it run to infinity when things don't work right.