Add fixme and default to none when srun and aprun are missing.

This can happen on an eslogin node.
Let the tasking layer say how much parallelism is available.

We're moving toward having the tasking layer tell the rest of Chapel
(notably the module code) how much parallelism it thinks it can provide,
instead of the module code (et al.) deciding that on its own based on
how much hardware it sees.  This is the first step along that path.  It
augments the processor-counting support in the runtime so that we can
get an accurate count of the number of cores and processor units (PUs,
basically anything that can issue instructions, including hyperthreads).
And, it adds a chpl_getMaxPar() call to the tasking layer interface, to
say how much true parallelism the tasking layer implementation thinks it
can provide.  Only the fifo and massivethreads layers are done so far,
and the module code hasn't been updated to use this information.  It's
still looking directly at how much hardware is configured.

The specific file changes are as follows.

runtime/include/chplsys.h
runtime/src/chplsys.c
  Rename chpl_numCoresOnThisLocale() as chpl_getNumPUsOnThisNode()
  (since #PUs is what it actually returned) and re-implement it for
  Linux to reflect kernel scheduling affinity, not just what hardware is
  present.  Add a new chpl_getNumCoresOnThisNode(), which returns the
  number of cores available to the process.  This new function is a copy
  of ...getNumPUs..., adjusted to return the number of actual cores (no
  hyperthreads or equivalent).  Make both of these return a regular int;
  chpl_numCoresOnThisLocale() returned an int64_t, but I can't think of
  a good reason to retain that.

runtime/include/chpl-tasks.h
runtime/src/tasks/fifo/tasks-fifo.c
runtime/src/tasks/massivethreads/tasks-massivethreads.c
  Add the new tasking interface function chpl_task_getMaxPar().
  Implement it in terms of chpl_getNumCoresOnThisNode() (added above).
  Also, in fifo tasking, call chpl_getNumPUsOnThisNode() instead of
  chpl_numCoresOnThisLocale() (which actually returned #PUs) when
  deciding whether to spin or use a pthread cond var while waiting for a
  sync var to be in the desired state.  And, while here, clarify the
  associated comment.

modules/internal/ChapelLocale.chpl
modules/internal/localeModels/flat/LocaleModel.chpl
  Add a new maxTaskPar member to the LocaleModel module, and initialize
  it by calling chpl_task_getMaxPar().

test/localeModels/gbt/maxTaskPar.chpl
test/localeModels/gbt/maxTaskPar.cleanfiles
test/localeModels/gbt/maxTaskPar.prediff
  Add a new test to ensure that here.maxTaskPar has the expected value.
Clean up in a few spots.

In chplsys, for Linux and Cygwin define chpl_getNumCoresOnThisNode() in
terms of the number of PUs returned by chpl_getNumPUsOnThisNode().

In flat/LocaleModel.chpl initialize numCores with the value returned by
chpl_getNumPUsOnThisNode(), which returns what used to be returned by
chpl_numCoresOnThisLocale().  Thus the value of numCores will be the
same as it was before all this work.
Add maxTaskPar support in qthreads tasking and numa locale model.

This adds chpl_task_getMaxPar() in qthreads tasking, and updates the
numa locale model to include a maxTaskPar member and initialization of
that.

While here, I also corrected the return types of the runtime functions
that return #PUs and maxTaskPar, in the extern decls in the flat locale
model.
Fix a function call I missed.

I neglected to change a call to chpl_numCoresOnThisLocale() into a call
to chpl_getNumPUsOnThisNode().  (It's a call that really is looking for
the number of PUs on the node.)
Merge branch 'master' of github.com:chapel-lang/chapel into taskrt-concurrency
Finalize support for numa and add darwin.

This fixes problems in maxTaskPar support with CHPL_LOCALE_MODEL=numa,
and adds support for the darwin (Mac) platform.  I've tested on linux
with tasks=(fifo,massivethreads,qthreads) and locale model=(flat,numa)
in all combinations, and on darwin with tasks=fifo and both locale
models.  Note: I've tested only the one new test, not anything else
(well, maybe a hello here and there).  That should be sufficient, since
I'm not yet changing behavior, just adding the new locale model member.

The specific file changes are as follows.

runtime/src/chplsys.c
  Take the #warnings out of the '#ifdef __APPLE__' code, so that it can
  build.  While here, also remove the #warnings for #ifdef __CYGWIN__,
  though I haven't been able to test that yet.

modules/internal/localeModels/numa/LocaleModel.chpl
  If there are no sublocales (as with CHPL_TASKS=fifo), set maxTaskPar
  to chpl_task_getMaxPar(), on the assumption that the tasking layer
  will behave like CHPL_LOCALE_MODEL=flat in this case.

test/localeModels/gbt/maxTaskPar.chpl
  Make this new test recursively print maxTaskPar for any sublocales.

test/localeModels/gbt/maxTaskPar.prediff
  Add a bunch of elaboration to compute what we think the program ought
  to print, and make a .good file containing that.
Initial commit to try and get rid of qthread deadlock

There are a couple of tests that deadlock with qthreads now that the nemesis
scheduler is the default. They are tests where the main task is in a loop
waiting for a sync var to have a certain value and other tasks are being
created inside the while loop to increment the sync var. Some of the tasks
getting created never get to run because the main task never yields and thus
the main loop is waiting for tasks that it's not letting run to update a value.
To remedy this the plan is to do a qthread_yield every x unlocks for any given
sync var. This does a qthread_yield every 1024 iterations. I tried with 32 and
256 and they both seemed to yield too often through the non-scientific method
of putting some prints when we yield and seeing how often we yield for a few
test programs and also checking how long they take to finish into account.
Improved constness checking on fields; adjusted Chapel code.
Fix updateBuildVersion bug so we don't always rebuild version.cpp

The updateBuildVersion script had a bug that caused it to always think there
was a new version. It was testing ("versionNum" eq versionNum), including
quotes as characters for one of the strings, so they are always different.
This just removes the quotes.
Update to how often qthreads yields for sync var unlock

This moves the check to use the return value of qthreads_incr, which means we
get the previous value of lockers_out but we get rid of a race.

The previous code was something like if (lockers_out & 0xFF) then yield but you
want if ((lockers_out &0xFF) == 0) since the other way yields for all but the
one iteration. Finally, this bumps up the number of unlocks before yielding.
This is based on trials with test/domains/sungeun/assoc/stress.numthr.chpl .
No stack checks, and smaller stack for domains/sungeun/assoc/stress.numthr.chpl

For qthreads this test was running out of memory because there were too many
tasks existing at the same time. This was especially a problem with 8M stacks
so this lowers that to 128 and turns of guard pages to reduce memory usage and
because this test creates a lot of tasks. I believe this wasn't an issue for
fifo because there is a limited number of pthreads (and thus stacks) that can
exist, whereas qthreads imposes no such limit.
Don't yield for first unlock of sync var for qthreads sync var unlock

Previously yield for if ((lockers_out % 4096) == 0) meant we would yield on the
first unlock. This just changes it to if ((lockers_out % 4096) == 4095) so that
we still yield after the same number of iterations but the first yield is moved
back to the 4095 unlock instead of the first.
Lower how many iterations until we yield
Merge pull request #159 from ronawho/qthreads-syncvar-deadlock

Do a qthread_yield() after X number of unlocks on a sync variable

Note: This idea was ok'd and comes from greg and sung. This exact patch hasn't
been reviewed, but it passed full testing and I want to see the performance
results so that we can setup something for good testing over the weekend and
hopefully switch to qthreads as default after the weekend. After seeing the
performance and correctness results I'll update the patch and have it formally
reviewed.

After switching to the nemesis scheduler as the default scheduler for qthreads
we had 5 deadlocks essentially coming from 2 tests:
test/domains/sungeun/assoc/stress.chpl and test/users/shetag/fock/fock-1.chpl.

In these tests the main task is waiting for a sync var to have a certain value
while other tasks are incrementing that sync var. In this case some tasks that
are adding to the sync var are put on to run on the same worker as the main
task. The main task is never yielding and thus it keeps waiting for a sync var
to have a value that it is preventing from getting updated.

To remedy this, we now yield after 256 unlocks of any given sync var. The
specific number has come from some trial and error with the previous tests and
will probably change after some more trial and error and looking through
performance results.

This also lowers the stack size for a test that creates an enormous amount of
threads and turns off guard pages to avoid running out of memory.
Minor changes to follow up on Tom's review
Merge pull request #157 from vasslitvinov/improve-const-field-checking

Improved constness checking on fields; adjusted Chapel code.


COMPILER CHANGES

functionResolution.cpp
wrappers.cpp

* Improved the logic of const checking added in SVN r22963.

** Check field accesses on result of *any* function with FLAG_REF_TO_CONST,
   not just field accessors.

** Check field accesses also to const formals, e.g. blank-intent records.

   For that, I replaced the check:  baseSym->hasFlag(FLAG_CONST)
   with:                            baseSym->isConstant()

** Propagate FLAG_FIELD_ACCESSOR and FLAG_REF_TO_CONST
   to wrappers.

* Factored out some const-checking code in resolveNormalCall()
  into a separate setFlagsForConstAccess().

* For now, promotion wrappers are not checked, due to scheduling concerns.
  There is a corresponding 'if' condition in setFlagsForConstAccess().
  This might produce incorrect errors in some cases, not exercised
  in our current code base.


MODULE CHANGES

* Switched the field locale.numCores to be 'var' (from 'const').
  That's because it is modified in RootLocale.init(), which
  is invoked outside of a constructor - in chpl_init_rootLocale().
  This was Sung's suggestion, making us forward-looking to having
  a node's core count adjustable at run time.

     modules/internal/ChapelLocale.chpl

* range.member no longer modifies its arguments. For that, I added a
  helper function that takes one of the arguments by 'in' intent, to
  indicate an explicit copy.

  I did not make the arguments of range.member themselves have 'in' intent,
  assuming that in many cases they will be passed by reference (blank
  intent), so copies will not be made.

     modules/internal/ChapelRange.chpl

* Changed several formals of the type 'qio_regexp_t'
  from 'ref' to 'const ref':

     modules/standard/Regexp.chpl
       qio_regexp_retain
       qio_regexp_get_options
       qio_regexp_get_pattern
       qio_regexp_get_ncaptures
       qio_regexp_ok
       qio_regexp_error

     modules/standard/IO.chpl
       qio_regexp_channel_match

  Correspondingly, in the runtime C code, changed
  qio_regexp_t* regexp  -->  const qio_regexp_t* regexp

     runtime/include/qio/qio_regexp.h
     runtime/src/qio/regexp/re2/re2-interface.cc
     runtime/src/qio/regexp/none/fail-regexp.c

  To motivate, consider for example proc =(ref ret:regexp, x:regexp)

    - It takes 'x' by blank intent. 'regexp' being a record,
      this means that 'x' is constant and it is illegal
      to modify its fields.

    - It passes x._regexp to qio_regexp_retain() by 'ref',
      which is considered to be a modification, and so is illegal.

  If we want at all to allow assignment from a "const" regexp,
  we want the above process to be read-only for 'x'. Therefore
  we want qio_regexp_retain() to be read-only as well.

  Another solution is to make a copy on the fly and modify that one.
  However, given that the modification is related to reference counting,
  that would not make sense.

  I consulted with Michael on the above and he expressed a preference
  not to bake constness into the interface. However he has not,
  as of this writing, offered an alternative solution.

* Replaced the blank-intent 'style' formal with 'in local_style',
  to indicate an explicit copy for local modifications, in:

     modules/standard/IO.chpl
       channel.channel()
       file.lines()

  Correspondingly, removed one 'local_style' variable.


TEST CHANGES

* range.member no longer modifies its argument

     test/arrays/vass/slices-with-negative-strides-1.good

* specify 'ref' task intent so the variable can be modified in a 'begin'

     test/parallel/begin/waynew/record1.chpl
     test/parallel/begin/waynew/record2.chpl

* pass a record by 'in' to allow local modifications;
  it looks like the actual better remains unmodified

     test/studies/hpcc/HPL/marybeth/HPL.chpl

* blank-intent record formals no longer allow field modification,
  so this future is removed

     test/types/records/const-checking/todo-assign-to-record-formal-error.future
changing .bad files to match the new parameters to open()
Merge pull request #160 from tzakian/open_sig_change

Changing .bad files to match the new parameters to open().
Merge pull request #158 from daviditen/updateBuildVersion

Fix updateBuildVersion bug so we don't always rebuild version.cpp

The updateBuildVersion script had a bug that caused it to always think there
was a new version. It was testing ("versionNum" eq versionNum), including
quotes as characters for one of the strings, so they are always different.
This just removes the quotes.

[reviewed by hildeth]