Fixed a bug that showed up in a code submitted by user wmikanik in
which a forall expression used in a reduction failed to compile for a
variety of reasons.  This was a tricky case to handle because a
variable in the forall expression is declared outside its scope.  Thus
we rely on nested functions.  There is code that specializes the
toFollower and toLeader functions so that they can be treated like
nested functions even though they aren't.  This allows the iterator
call to be reconstructed in these functions.  This commit expands this
special handling to the toFollowerHelp function as well.
(flattenFunctions)

In addition, denested the toFollowerHelp function in the modules so
that the special casing above can apply.
(ChapelArray)

Finally, handled iterators via references (previously assumed never to
be references) and ensured that the actuals which are replaced by a
field are only those that need to be.
(lowerIterators)


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15326 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixed the bug in the test case Steve checked in today
which has to do with having a return statement that is not inside any function.
This was fixed by removing the return statement that was added to every init
function, and then making the check for return statements outside of functions
to apply to any return statement, not just those that actually return a value.

This also has the side benefit of getting rid of a goto in the init functions,
which means that anything that would otherwise be freed were it not for the
presence of this goto can now be freed.

The reason the goto was being inserted is that there was a check at the
beginning of every init function to make sure it was not being executed more
than once.  This check is still needed, but it now appears in all the places
that call init functions, rather than inside the init functions themselves.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15327 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Moved the call to free strings just after the first use
in cases in which there is just one use.  There are two cases that require
special consideration:

1) If this one use is in a primitive move to another variable, then the
   destination variable must also have just one use.  In this case, the call
   free the string appears after the use of the destination variable.

2) If this one use is inside a loop, then the outermost loop that encloses
   this use is found, and the call to free the string is placed just after
   the end of this outermost loop.

In addition, some code was simplified, and some .good files were updated to
account for the additional memory used by the recently-added string copies.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15328 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removed PRIM_BLOCK_INLINE_FOR_LOOP since it is never used


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15329 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Renamed some symbols that begin with an underscore

_heapAllocateGlobals -> chpl__heapAllocateGlobals
_initModuleGuards -> chpl__initModuleGuards
_Program -> chpl__Program


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15330 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating REGRESSIONS based on weekend's runs

+ most general memory regressions fixed (remaining one in my court)
+ race in debugBlock1D test fixed
- new signal 11 failure in baseline testing on xml-parse
* noted a few spurious regressions



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15331 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Changing %d to PRId32 to make g++ 3.4.4 happy

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

Updating the output file for allocAndFree to reflect the new
max memory numbers that result from copying and freeing
strings.  This seems worth tracking, but if it ends up being
too fragile across future changes, we can reconsider -- in
particular, I believe we could remove a bunch of writelns() and
make strings empty in order to get back to our previous .good
file.  But let's see how this version goes.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15333 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Killed some commented out code

Noticed this in a code review with Lee today.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15334 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removed dead comm-* include directories

In a code review with Lee, (re-?) noticed that the comm-*
include directories don't serve any useful purpose and
clutter up the command line.  This removes the directory
and their use in the various compile commands.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15335 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Implemented a number of GASNet Makefile-related cleanups

Most of these cleanups were suggested by the GASNet team or motivated
by their feedback:

* added --disable-seq, --enable-par, and --disable-parsync to our
  GASNet configure line since we rely on GASNet par to do anything
  interesting in our current use in Chapel

* replaced a number of a number of manually-inserted GASNet CC flags
  with the GASNET_CPPFLAGS and GASNET_CFLAGS macros

* removed explicit #define of GASNET_PAR in chpl_cfg_comm.c -- now get
  this from GASNET_CPPFLAGS macros

* cleaned up rules for include-ing and building the GASNet .mak file

* removed unused Makefile variable CHPL_GASNET_CONDUIT

* removed some GASNet stuff from the comments of
  runtime/comm-mpi/Makefile.share to keep things clean for grepping
  purposes





git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15336 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Deleting old GASNet version

I think we're at a point where we're fairly committed to GASNet-1.12.0,
so the deletion of 1.10.0 is probably overdue.



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

A batch of svn:ignore mods to try and unclutter my svn status
messages...



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15338 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating REGRESSIONS based on last night's tests

+ allocAndFree passing due to .good fix
- everything failing with --no-copy-propagation flag -- output comes
  out blank.  I have no idea which change caused this
- ra-dist regression on linux32 -- apparently spurious




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15339 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding/updating some regression testing scripts



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15340 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding template for PVM runtime code to be worked on.

This change adds the framework for adding a PVM runtime. This includes the launcher and the communications with associated build and run utilities which include the Makefiles and the config (environment) update. Right now, for any function call with CHPL_COMM set to pvm, the code returns a to-do message. For now, this starts with the top of the launcher code, but as the real production code gets filled in, the return and exit will occur deeper into the run.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15341 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Applying recommended GASNet patch

In email conversations with Paul today, he suggested we grab the
following patch as it fixes some seg faults on recent x86_64
architectures.  I'm not sure at this point whether the problems
show up in a spurious fashion (in which case this might explain
some of the nondeterministic seg faults we've been seeing) or
deterministically (in which case it might explain the seg faults
I've been getting on CX1 with the IBV conduit).

The official webpage of the patch is here:

  http://upc.lbl.gov/download/patch/berkeley_upc-2.8.0-patch1.shtml

I added mention of this patch to our README.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15342 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating runtime's TAGS command to reflect removing include/comm-* dirs

Since I removed the include/comm-* directories yesterday, the TAGS
command we run on the runtime started complaining since it was
trying to index those directories.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15343 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing and refactoring extra Chapel C flags for compiling GASNet

Previously, we were embedding gnu-specific -Wno-* flags into
GASNet's Makefile.share file, causing them to be used for all
compilers.  Moved these into Makefile.gnu and Makefile.intel
to support those two compilers for now.  Eventually, we may
need to do similar things for other compilers (but note that
these are only used when CHPL_DEVELOPER is true anyway, so
it shouldn't affect our end users).

Also, fixed a problem that Steve reported last week in which
we were no longer throwing -O0 when compiling GASNet with
CHPL_COMM_DEBUG on but CHPL_DEVELOPER off.  This broke the 
compile.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@15344 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Trying to remove most svn:ignore options from GASNet directory

Previously, we had set svn:ignore on the GASNet-1.12.0 directory
to include configure and a few other files because Steve kept
checking in changes to them accidentally.  The GASNet team
asserts that this shouldn't be necessary if we build and install
correctly.  I feel like it has been at times, but can't seem
to reproduce it right now, so am disabling these ignores for
the time being to help determine when they show up.

So, if anyone finds that they have modifications in their GASNet
directory as a result of simply building GASNet (or the runtime
or ...?) please let me know what you're doing to get that
behavior.  Thanks.



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