First try at .good files to make dist-replicated pass.
Suppress constOverflow test when CHPL_TARGET_COMPILER==clang.
Add declint2.skipif to skip when --fast is tossed.

This test (declint2) is intende to show that GDB will stop when a deliberate
out-of-bounds array access is attempted.  But bounds checking is turned off when
--fast is tossed, so this test does not pertain.
Get rid of warnings about non-literal printf() format strings on darwin.

On darwin we get warnings from the gen compiler about non-literal
printf() format strings in these three tests, causing them to fail.
Resolve these warnings as follows:

test/extern/hilde/namedExtern.chpl
  We declare printf() such that the fmt argument is implicitly typed
  by the corresponding actual argument.  That actual arg is a literal
  string, but of type Chapel string.  The compiler emits code to
  convert it to a c_string for the call to the extern printf(), but
  this ends up making the actual a variable in the emitted code.
  Change the printf() declaration(s) so that the fmt argument is
  explicitly a c_string.  This makes the compiler emit the literal as
  a c_string in the first place, and we don't get conversion code or
  the resulting variable.

test/io/vass/time-write.chpl
  In this case we actually do need to be able to printf() non-literal
  strings.  As the code stands we send these as the first (format)
  argument to printf().  Since we need to prnt non-literal strings,
  change the calls (and declarations) so that we use a "%s" format and
  pass the c_string to print as the second argument.  Arguably this
  adds a slight amount of overhead to the printf() call and thus
  changes the test.  If this is a problem we'll need to discuss the
  point of the test, in particular whether it is testing printf()
  performance or the performance of the C buffered I/O FILE interface.
  If the latter, we could call puts() here instead of printf().

test/studies/pidigits/bbp/nomem32.chpl
  This has the same problem as namedExtern, above.  The printf("\t")
  here is the only printf() call in the program.  Everywhere else we
  use Chapel write.  Convert the printf() to a write().
Do not run cobeginRace.chpl when doing memleaks testing.
Merge pull request #728 from vasslitvinov/skip-cobeginRace-for-memleaks

Do not run cobeginRace.chpl when doing memleaks testing.

Currently this test times out when running memory leak testing.
We decided not to run it there - see the thread on the internal list re
"parallel/cobegin/diten/cobeginRace regression".

Here is a summary.

Why does it time out?
* Memory leak testing currently runs on a virtual server, with qthreads.
* This test creates lots of tasks; at most 12 tasks are created at once.
* It runs a lot faster with guard pages disabled.
* So we conjecture that guard pages are very slow on that machine.

Can this test be made to succeed in this context? Yes, e.g.:
* turn off guard pages
* increase the timeout
* reduce the number of iterations
Re the last two... In 2008 this test ran quickly on computers that
were old back then - see commit 5bd5df6. So we want to keep the current
size and timeout in our other contexts.

Note also that this test currently does not generate memleaks info.
That's because it calls exit() (from ChapelBase.chpl), and that bypasses
the memleaks dump. And even if it didn't, we currently not do
any structured teardown upon exit(). So the memleaks report would be
very long, and not very useful.
Merge pull request #725 from hildeth/master

A couple of cleanup skipifs

I added a line to constOverflow.skipif to catch the case when the target compiler is "clang" (on darwin).
I added the execopts/bradc/gdbddash/declint2.skipif to skip that test when --fast is tossed on the Chapel command line.
Revert "Add declint2.skipif to skip when --fast is tossed."

This reverts commit 1436e0245e4936149156884f400dae173f4effa5.

The failure is already coveredy in Suppressions.
Avoid relying on qthreads syscall interception for chpl_task_sleep

chpl_task_sleep() was previously just a call to sleep(). This system call is
supposed to be intercepted by qthreads, and qthreads will perform
qthread_yields until the specified sleep time is up. If that doesn't happen
sleep, would cause the entire worker to sleep, preventing other tasks on the
same worker from running.

The system call interception does not seem to be working on darwin currently.
As a result any test with sleep() in it fails on darwin.  We're working with
the qthreads team to figure out what's going on but in the meantime (and
possibly longer term) we will just perform what the syscall interception is
supposed to do directly.
Merge pull request #731 from hildeth/master

Revert "Add declint2.skipif to skip when --fast is tossed."

The failure is already covered in Suppressions.
Add classes/figueroa/RecordConstructor2.skipif

This test arguably works correctly in both configurations, even though its output differs
when run with the --baseline option compared to when run without it.  That is because
--baseline disables the removeUnnecessaryAutoCopyCalls() optimization.  The compiler may
add or remove autoCopy calls at will, so the user should not write code that depends upon
its having run (except as needed for memory management reasons).

In this test, running autoCopy has a side-effect (setting the contents of the record to
2).  The autoCopy function does this because every constructor implicitly calls the
initialize() function, and that is what is done by the initialize() function for this
record type.

The compiler could do a better job of aligning --baseline vs. optimized behavior by
inserting fewer autoCopy calls to begin with.  Also, the fact that the compiler-generated
autoCopy calls initialize is quite hidden.
Reduced the problem size for test_array_slicing3
to avoid timeouts during nightly testing.
Merge pull request #727 from gbtitus/darwin-non-literal-format

Get rid of warnings about non-literal printf() format strings on darwin.

On darwin we get warnings from the gen compiler about non-literal
printf() format strings in these three tests, causing them to fail.
Resolve these warnings as follows:

test/extern/hilde/namedExtern.chpl
We declare printf() such that the fmt argument is implicitly typed
by the corresponding actual argument. That actual arg is a literal
string, but of type Chapel string. The compiler emits code to
convert it to a c_string for the call to the extern printf(), but
this ends up making the actual a variable in the emitted code.
Change the printf() declaration(s) so that the fmt argument is
explicitly a c_string. This makes the compiler emit the literal as
a c_string in the first place, and we don't get conversion code or
the resulting variable.

test/io/vass/time-write.chpl
In this case we actually do need to be able to printf() non-literal
strings. As the code stands we send these as the first (format)
argument to printf(). Since we need to print non-literal strings,
change the calls (and declarations) so that we use a "%s" format and
pass the c_string to print as the second argument. Arguably this
adds a slight amount of overhead to the printf() call and thus
changes the test. If this is a problem we'll need to discuss the
point of the test, in particular whether it is testing printf()
performance or the performance of the C buffered I/O FILE interface.
If the latter, we could call puts() here instead of printf().

test/studies/pidigits/bbp/nomem32.chpl
This has the same problem as namedExtern, above. The printf("\t")
here is the only printf() call in the program. Everywhere else we
use Chapel write. Convert the printf() to a write().
Bump timeout for gasnet+qthreads testing on low core count machines

On low core count machines like the linux32 box, lnx-diten, and lnx-vass we
still have some timeouts with gasnet+qthreads even when built with
oversubscription on and affinity off. The reason we see it on these machines
but not for regular gasnet testing is just because these machines have a lower
core count.

This increase in timeout does NOT reflect true performance issues with
qthreads, but merely the fact that qthreads wasn't designed to run in an
oversubscribed manner. Qthreads expects that it owns the whole machine. With
oversubscription on, amongst other things, busy loops turn into loops with
sched_yield in them. While this yields the processor, the qthread is not
yielded and so there are still situations where it takes much longer to get
work done because qtheads doesn't own the whole machine, but fundamentally
assumes it does.

Increasing the timeout is a stop-gap to quiet nightly testing until I figure
out a better solution, or we start doing gasnet testing on real hardware.

I tried a few things to get rid of timeouts with little success including
modifications to qthreads source, and limiting CHPL_RT_NUM_THREADS_PER_LOCALE
to numCores/numLocales. Limiting the number of threads doesn't help on low core
count machines because you get 1 thread per locale, which is equally as slow as
the contention in most cases.

I can look for a better solution as a background test, but this will quiet
testing in the meantime.
Merge pull request #732 from hildeth/quietRecordConstructor2

Add classes/figueroa/RecordConstructor2.skipif



This test arguably works correctly in both configurations, even though its output differs
when run with the --baseline option compared to when run without it. That is because
--baseline disables the removeUnnecessaryAutoCopyCalls() optimization. The compiler may
add or remove autoCopy calls at will, so the user should not write code that depends upon
its having run (except as needed for memory management reasons).

In this test, running autoCopy has a side-effect (setting the contents of the record to
2). The autoCopy function does this because every constructor implicitly calls the
initialize() function, and that is what is done by the initialize() function for this
record type.

The compiler could do a better job of aligning --baseline vs. optimized behavior by
inserting fewer autoCopy calls to begin with. Also, the fact that the compiler-generated
autoCopy calls initialize is quite hidden.
Merge pull request #730 from ronawho/qthreads-sleep-on-darwin

Avoid relying on qthreads syscall interception for chpl_task_sleep

[reviewed by @gbtitus]

chpl_task_sleep() was previously just a call to sleep(). This system call is
supposed to be intercepted by qthreads, and qthreads will perform
qthread_yields until the specified sleep time is up. If that doesn't happen
sleep, would cause the entire worker to sleep, preventing other tasks on the
same worker from running.

The system call interception does not seem to be working on darwin currently.
As a result any test with sleep() in it fails on darwin. We're working with
the qthreads team to figure out what's going on but in the meantime (and
possibly longer term) we will just perform what the syscall interception is
supposed to do directly.
Merge pull request #729 from ronawho/qthreads-gasnet-timeouts

Bump timeout for gasnet+qthreads testing

[ok'd by @gbtitus]

On low core count machines like the linux32 box, lnx-diten, and lnx-vass we
still have some timeouts with gasnet+qthreads even when built with
oversubscription on and affinity off. The reason we see it on these machines
but not for regular gasnet testing is just because these machines have a lower
core count.

This increase in timeout does NOT reflect true performance issues with
qthreads, but merely the fact that qthreads wasn't designed to run in an
oversubscribed manner. Qthreads expects that it owns the whole machine. With
oversubscription on, amongst other things, busy loops turn into loops with
sched_yield in them. While this yields the processor, the qthread is not
yielded and so there are still situations where it takes much longer to get
work done because qtheads doesn't own the whole machine, but fundamentally
assumes it does.

Increasing the timeout is a stop-gap to quiet nightly testing until I figure
out a better solution, or we start doing gasnet testing on real hardware.

I tried a few things to get rid of timeouts with little success including
modifications to qthreads source, and limiting CHPL_RT_NUM_THREADS_PER_LOCALE
to numCores/numLocales. Limiting the number of threads doesn't help on low core
count machines because you get 1 thread per locale, which is equally as slow as
the contention in most cases.

I can look for a better solution as a background test, but this will quiet
testing in the meantime.
Added to .gitignore and CLEANFILES.
Fix static_dynamic for intel compiler

It turns out that -Bstatic fails to find a static library in one case and
causes compilation to fail.  The correct combination to ensure complete and
static compilation is -static-intel -static-libgcc -static.  These tests should
now pass (phew!).
Have serial tasks directly execute the function for qthreads

Previously, serial task creation spawned a new task, and the original task
would wait for that task to complete. We believe the original motivation for
this is from the days when qthreads had a lower stack size. If you have
recursive serial tasks being created you're going to run out of stack pretty
quickly.

This was changed with the qthreads commit 82a0224513ec

With our current default stack size of 8MB you end up wasting a lot of memory
because you're creating a task for each serialized task. For schedulers that
have more than one worker per shepeherd you can also schedule the serial task
on a different core, which can cause you to lose some cache and can result in
slowdown because many qthreads are constantly yielding waiting for one to
finish.