Have Cray X* and CS machines use GASNet by default. [reviewed by Brad]

Changes the scripts so that when the user sets the platform to cray-x* or
cray-cs, we automatically assume they want to use GASNet unless they specify
a different comm layer.  Also, updates the relevant documentation files
(doc/release/platforms/README.cray, doc/release/README.chplenv) to reflect
this change.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21911 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Allowed 'begin' in internal modules under --no-devel; refactored codegen for local task creation.

-----------
What is the bug?

The bug happens when there is a 'begin' in an internal module and the
compilation is with --no-devel.

In this case, the corresponding  wrapbegin_fn gets the additional (line,file)
arguments. This happens when insertLineNumber() is invoked on a PRIM_MOVE
inside that wrapbegin_fn. When the above two conditions hold, the
control goes to insertLineNumbers.cpp:134 (the second time around, to :129),
otherwise to :112. newLine/newFile at :134 force those (line,file)
arguments on the wrapbegin_fn.

Then, codegen for a call to the wrapbegin_fn assumes endCount is the last
argument (expr.cpp:5190), but it is not - because (line,file) follow it.
endCount is not necessarily the first argument, either.

The reason we have not seen this before is because we have not had a
'begin' in an internal module.

NB line numbers are given for the pre-commit version of expr.cpp.

-----------
What is the fix?

Remove the assumption that endCount is the last argument.
Codegen for calls to cobegin/coforall wrappers already dispenses with this
assumption (expr.cpp:5236), so we can simply do the same for begin wrappers.

-----------
While there...

This commit also merges the handling of 'begin' wrappers with the
handling of the 'cobegin'/'coforall' wrappers in the expr.cpp code
referenced above.

The two cases are very close, so I merged them into one.
But see the "Here are the places" section below.

I also eliminated the else of "if (Expr *actuals = get(1))" (:5183)
- because the condition is always true.

-----------
Here are the places where the handling of FLAG_BEGIN_BLOCK and
FLAG_COBEGIN_OR_COFORALL_BLOCK differed:

* Cases over endCountType->symbol->hasFlag(...), aka
  bundledArgsType->getField(lastField)->typeInfo()->symbol->hasFlag(...),
  when computing 'taskList' aka args[3]:

 - 4 cases for cobegin/coforall:
    FLAG_WIDE
    FLAG_WIDE_CLASS
    FLAG_REF
    other

 - 2 cases for begin:
    FLAG_WIDE_CLASS
    other

  In the merged code, I kept all 4 cases. I verified that each case happens.

* Cases over the same when computing args[4]:

 - 2 cases for begin:
    FLAG_WIDE_CLASS => codegenRnode(endCountPtr)
    other           => codegenGetNodeID()

 - no cases for cobegin/coforall:
    always codegenGetNodeID()

  In the merged code, I kept the 2 cases as for begin.

-----------
Open issues

* When searching for the endCount field (expr.cpp:5236), it would make
sense to ensure there is only one. This would guard against the cases
where Chapel code unwittingly refers to something of the _EndCount
type. However unlikely that is to happen.

  Turns out that there *are* cases where there is more than one such
field. Historically we have been picking the first one we come across.
I left it as-is and added comments. TODO - need to investigate.
"This could be a nasty bug if one runs into it." -Sung

* Sung suggests: "I think we should add a flag to mark the [_EndCount]
class declaration (and pass that on to the wide+ref version).  Then
the strcmps [when looking for the _endCount field], can just look for
the flag (and we can change the name, etc.)."

* The endCount variable itself currently gets remote-value-forwarded,
if we are lucky (i.e. no sync ops in the task). However, it is really
a constant pointer - given that _EndCount is a class (not a record).
I would like to mark it with FLAG_CONST so that the pointer is always
passed directly rather than by reference when flattening functions.

  With the upcoming capture-for-tasks language change, this will be an
issue only for sync statements with lexically-intervening nested functions.
In the other cases that pointer will be captured automatically.
Therefore I am deferring this change.

  Sung notes that if we mark _EndCount with a flag, we can check that
it is a class early on during compilation.

* I am uncertain whether the following makes sense. Two things drew my 
attention: the check node(endCount) != getNodeID() and producing NULL if 
that's true.

       taskList = codegenTernary(
                      codegenNotEquals(node, codegenGetNodeID()),
                      codegenNullPointer(),
                      taskList);

  Given that I do not know what's going on and that it has worked fine,
I am leaving this alone for now.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21912 3a8e244f-b0f2-452b-bcba-4c88e055c3ca