Bumping up timeouts for miniMD

I thought I had committed these on Friday, but apparently not.
Bumping timeouts to 10 minutes just to get rid of timeout noise
temporarily.  In hand-inspecting, I'm not seeing any specific
phase that runs slower on, say, chpbld01 than on other machines.
The whole thing is simply significantly slower for some reason.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21999 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Filing a future against r21300 regression

This is a slightly more interesting variation on my simplified case of
the nil dereference error that I've been tracking down this weekend.
As noted on email and in the future, it seems to have come about in
r21300.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22000 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Small wording improvement around use of 'aprun' launcher



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22001 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding a bug showing that HDFS is broken

Something about r21915 seems to have broken our ability to use HDFS (I
asked Tim to kick the tires to make sure bitrot hadn't set in since
the release).  This trivial test shows the problem.  I've asked
David/Vass to take a look.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22002 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Moving thread-ring to the release directory as threadring caused perf testing to
lose the release data.  This should cause it to get the new data.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22003 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding massivethreads version 0.95 to the third-party directory






git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22004 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing tarball now that it's archived



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22005 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix assertion error on specifying two --log= flags. [reviewed by sungeun]

The static Vec<char> valid_log_flags only needs/wants to be initialized once, so
I added a test before the call to initLogFlags(), to skip it on second and
subsequent invocations of log_flags_arg().


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22006 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Switching MassiveThreads to use version 0.95

[Contributed by Jun Nakashima, minor textual edits by me during review]

This updates Chapel to use massivethreads 0.95 when
CHPL_TASKS=massivethreads, and provides updates to the
READMEs and Makfiles to support that.

removing the 0.3beta version of massivethreads.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22007 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixed a bug in the implementation of "capture for tasks" of r21940.
Also clarified capturing for coforall index variables.

THE BUG was that certain variables that should be captured, weren't.

Let's say we are compiling this source program:

  iRef:int comes from outside 'begin'
  ...
  begin {
    iRef = 5;      // (a)
    writeln(iRef); // (b)
  }

With capture-for-tasks, (a) is illegal. In the absence of that, (b)
should use the captured copy of the original iRef.

Before this change it worked -- except if, at resolution time, iRef is a
reference, i.e., _ref(int(64)). This can happen, e.g., if iRef
is a 'ref' formal or an index variable of a loop with a 'var' iterator.
Capturing is still required, but was not happening.

In this case, the begin_fn still takes iRef by blank intent, but iRef's
type is a _ref:

  proc begin_fn(<blank> iRef: _ref(int(64))) {
    iRef = 5;
    writeln(iRef);
  }

Therefore it is the pointer (that is stored in the outer iRef),
not the pointee, that is passed into begin_fn. Its being a ref
fools the compiler into allowing iRef=5. At run time, that updates
the pointee of the outer iRef.

THE FIX is to check for reference types in handleCaptureArgs (see
r21940). When the type of a variable that is being passed into the
task function is a _ref of a type that is subject to capture (e.g.
ints, records, etc.):

- Replace the type of the task function's corresponding formal
with the value type.

- Replace the actual with a temp that holds a dereference of
that actual.

- Update the corresponding CallInfo appropriately.

>> functionResolution.cpp
 handleCaptureArgs
 replaceActualWithDeref
 resolveNormalCall

I ignored the cases when the dereference type is not subject to
capture, e.g. it is an array or a synchronization type. That's
because I have not seen any issues in those cases and prefered
to leave the behavior unchanged for simplicity.

>> type.cpp
  needsCapture(Type*)

Discussion: It is almost enough to just replace the type of the task
function's formal (i.e. the first of the above actions). However,
this results in a coercion wrapper around the call to the task function.

As a result, handleCaptureArgs() is invoked once again on that task
function, although now with a different CallExpr. This is OK, especially
there is still only a single call site per task function, i.e. it
is still invoked only once.

But unfortunately this interferes with lowerIterators. I observed
PRIM_YIELD calls surviving until codegen, e.g., in release/ssca2.
I did not investigate, but I had flashbacks to my work on r21426.
There, a major challenge was go get traversals of an iterator examine
the now-outlined task functions - iterator yields could now
end up in those functions, but they still needed to be found
and handled properly.

Replacing the actual with a dereference seemed easier than
investigating the yield issue, so that's what I did.

As a side benefit, in some cases references to variables
used to be captured (resulting in indirections within
the task functions, I expect), and now values are
captured instead (correct and more efficient).

BTW TODO I suggest making a similar change in coercionWrap().
That is, in the case of ref-deref difference, replace the actual
using replaceActualWithDeref(), rather than handle it in the wrapper.
This will obviate some wrappers altogether.

THE CLARIFICATION is that an index variable of a coforall loop
is not subject to capture for the loop body task.
It is still subject to capture (depending on its type)
for any task construct *within* that loop body, e.g. a
nested coforall.

To implement that, I extended findOuterVars to drop such variables.
I added isCorrespCoforallIndex() to detect whether a variable is
an index of a coforall loop, relying on FLAG_COFORALL_INDEX_VAR
and matching the parentExpr of the variable's DefExpr vs.
that of the task construct's block/task function.

A more robust check would also verify that the index variable
comes from the _indexOfInterest. Given that this is a bit of
work in the case where the coforall is zippered, I chose to
conclude that that was not necessary.

>> createTaskFunctions.cpp
 isCorrespCoforallIndex
 findOuterVars

TEST CHANGES were also necessary because in a couple of places
the assigning-to-constant (aka "illegal lvalue in assignment")
check used to being fooled by the captured variable's ref-ness.
ref-intent-bug-4begin.chpl now works under all configurations,
so I removed the .skipif.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22008 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Tidy up functions/vass/ref-intent-bug-*.

* Now succeed for both gasnet and comm=none,
so removed .skipif:

  ref-intent-bug-1small.chpl
  ref-intent-bug-3med.chpl

* Now crashes at run time under gasnet (segfault).
Updated .future correspondingly:

  ref-intent-bug-2big.chpl


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22009 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Retire parallel/begin/vass/this-in-begin-in-method.future.

This test now succeeds for both gasnet and comm=none -
so I am enabling it for all configurations.

According to r21602, we should now be able to remove:

  parallel/begin/vass/this-in-begin-in-method.chpl

- the entire test, because allegedly it is covered by the test:

  multilocale/vass/this-in-taskfns-in-ctors.chpl

However, the latter is now failing under GASNET, so I will hold off
removing the former. (Also, another todo from r21602: move
the latter from multilocale into, say, altogether.)


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22010 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Propagate special function flags to wrapper functions

[reviewed by Brad]

This fix propagates FLAG_INIT_COPY_FN, FLAG_AUTO_COPY_FN,
FLAG_DONOR_FN, and FLAG_AUTO_DESTROY_FN to the wrapper functions
created during function resolution.  For these four types of
functions, previous to r21300 the wrappers were being treated as if
they were the actual function they were wrapping in certain situations
(e.g., resolution, callDestructors) by naming them the same (though
they were given a different cname).  In r21300, almost all the
strcmp() against these function names were changed to flag checks, but
such wrappers were not given the appropriate flags.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22011 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove XMT support.  [reviewed by gbt]

All code related to the XMT platform and MTA tasking layer was removed.

The noalias pragma and block_xmt_pragma_forall_i_in_n primitives were removed.
The sync_reset and single_reset primitives were removed.

The primitive_loop token was removed.

buildPrimitiveLoopStmt() is called only for XMT platforms, so it was removed.
The repositionDefExpressions pass was used only when compiling for the XMT
platform, so that pass was removed along with the --reposition-def-expressions
command line argument and supporting boolean.

XMT-related keywords were removed from reservedSymbolNames

In ChapelSyncvar.chpl, the isSimpleSyncBaseType() predicate is used only to
support XMT, so it was removed.

The second argument of the sync_is_full and single_is_full primitives was true
only for XMT, so the argument was removed.  In non-MTA tasking layers, this
argument was unused anyway.

In certain tests, syncvar.reset() was being called unnecessarily at the
beginning of the program.  These reset calls were removed.

Removed files and directories:
D       test/release/examples/benchmarks/lulesh/lulesh.skipif
D       test/memory/sungeun/no_unreachable_autoDestroy.future
D       test/memory/sungeun/no_unreachable_autoDestroy.skipif
D       test/memory/sungeun/no_unreachable_autoDestroy.chpl
D       test/memory/sungeun/no_unreachable_autoDestroy.good
D       test/parallel/cobegin/gbt/cobegin-stacksize.skipif
D       runtime/include/tasks/mta
D       runtime/include/tasks/mta/tasks-mta.h
D       runtime/include/comp-cray-mta
D       runtime/include/comp-cray-mta/chpl_md.h
D       runtime/src/tasks/mta
D       runtime/src/tasks/mta/Makefile.include
D       runtime/src/tasks/mta/tasks-mta.c
D       runtime/src/tasks/mta/Makefile
D       runtime/src/tasks/mta/Makefile.share
D       runtime/src/timers/mta
D       runtime/src/timers/mta/Makefile.include
D       runtime/src/timers/mta/timers-mta.c
D       runtime/src/timers/mta/Makefile
D       runtime/src/timers/mta/Makefile.share
D       runtime/src/launch/zebra
D       runtime/src/launch/zebra/Makefile.include
D       runtime/src/launch/zebra/launch-zebra.c
D       runtime/src/launch/zebra/Makefile
D       runtime/src/launch/zebra/Makefile.share
D       runtime/src/launch/mtarun
D       runtime/src/launch/mtarun/Makefile.include
D       runtime/src/launch/mtarun/launch-mtarun.c
D       runtime/src/launch/mtarun/Makefile
D       runtime/src/launch/mtarun/Makefile.share
D       doc/release/platforms/README.cray-xmt
D       compiler/passes/repositionDefExpressions.cpp
D       util/cron/nightly.xmt
D       util/cron/nightly-mta.cron
D       make/compiler/Makefile.cray-mta

[tested --no-local --verify and gasnet-DDMP]


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22012 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Moving the contents of thread-ring into a subfolder caused the SKIPIF to no
longer apply to those files, meaning that they turned up in Valgrind testing
again.  This should fix that error.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22013 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Use param localeModelHasSublocales in range and DefaultRectangular leaders

[Reviewed by Sung]

Instead of using (numSublocs != 0) to decide if there are sublocales, use
(localeModelHasSublocales && numSublocs != 0).  This allows the choice to be
made at compile time when localeModelHasSublocales is false, as is the case in
the flat locale model. This avoids a small memory leak regression in
memory/figueroa/LeakedMemory5 and also reduces code size for parallel iterators
in the flat model.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22014 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Draft CONTRIBUTORS file for upcoming release

This is a proposed CONTRIBUTORS file for the upcoming release.  I
haven't scraped the logs completely yet to make sure I haven't
forgotten anyone, but I think this is close.  Please make sure I've
spelled your name correctly, gotten your institution right, etc.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22015 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Move the removeRandomJunk() pass to after insertRuntimeTypeTemps() in resolution

[Reviewed by Sung, Tom]

The pass insertRuntimeTypeTemps() can insert calls to methods that include
methodTokens. One of the things removeRandomJunk() removes is methodTokens and
we expect them to not exist anymore after it is run. Reorder these two
passes so the methodTokens get cleaned up. This should fix codes that use the
HDFS module.

I also added test/arrays/diten/distArrInRecord.chpl, which declares a
distributed array as a record field and fails in the same way as programs that
use HDFS prior to this revision.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22016 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Bumping version number to 1.8.0 in anticipation of upcoming release




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@22017 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixed a bug in heap allocation (exhibited by parallel/taskPar/figueroa/taskParallel.chpl under --local).

[reviewed by Sung]

The bug arises (under --local && !NUMA) when a global variable is passed
as an actual to a task function, and the corresponding task function formal
has a _ref type.

Given that:
- variables listed in a 'ref' clause do not count,
- arrays/domains/distribs are excluded,
- syncs/singles are not passed with _ref (the formal has a _syncvar type),

this was observed only for atomics, since r21924.

The bug is that makeHeapAllocations() was assuming that such a global
was heap-allocated, and so changing accesses to the actual value to
accesses via the global's _value field.

MHA delegates the actual heap allocation to insertWideReferences().
There, it happens only if requireWideReferences(),
which is false under --local && !NUMA.

As a result, accessing via the _value field fails the check that
the global itself is not NULL.

Since under --local && !NUMA there is no need to heap-allocate
globals, I made makeHeapAllocations() not modify accesses to
use _value for globals.

TODO: if globals do not need heap allocation when !needHeapVars()
(i.e., currently, when --local or UGNI or GASNET-everything -
a wider set of configurations than requireWideReferences()),
we should change the logic in insertWideReferences() w.r.t.
heapAllocateGlobals/chpl__heapAllocateGlobals().

The actual code change in this commit is 5 lines.
The rest are comments, including the following,
which is my best-effort summary of the current state:

Notes on
  makeHeapAllocations()    //invoked from parallel()
  insertWideReferences()

------
Terminology/abbreviations:

'on'+'begin' is considered to be both an 'on' and a 'begin'
- see also FLAG_NON_BLOCKING

A "global" is a module-level symbol, usu. a VarSymbol.
A 'var' is a global if, equivalently:
 isModuleSymbol(var->defPoint->parentSymbol)
 isGlobal(var)

MHA = makeHeapAllocations() and functions it invokes
IWR = insertWideReferences() and functions it invokes
------

MHA and IWR take care of the following, among others:
- heap allocation for remote access
- heap allocation for 'begin'
- change acces to variable -> access to its ._value
- set up wide references
- broadcasting of globals

In more details:

Heap allocation for remote access is done:
- for globals - in IWR, if:
   requireWideReferences()
- for a local - in MHA, if:
   needHeapVars() && the local can be passed to an 'on'

Heap allocation for 'begin' is done:
- for globals - n/a
   see above instead
- for a local - in MHA, if:
   the local can be passed to a 'begin'

Change acces to variable -> access to its ._value
- for globals - in MHA, if:
   requireWideReferences()
- for locals - in MHA, if:
   the local is subject to heap allocation
   in either of the above two categories

Wide references are set up in IWR, if:
   requireWideReferences()

Broadcasting:
- of certain global constants       - in MHA/findHeapVarsAndRefs, if:
   !fLocal
- of global arrays/domains/distribs - in MHA/findHeapVarsAndRefs, if:
   !fLocal
- of locations of the other globals - in IWR, if:
   requireWideReferences()


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