Further dialing down numThreadsPerLocale for aniruddha's madness tests

The test test_likepy.chpl is still timing out, so dialing this down
further.  The lower number also seems to make all the tests run
faster, at least when there is another set of tests running
concurrently (which is what we do nightly).



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20125 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixes type-punned pointers in comm-gasnet.

[reviewed by Sung and Greg]

We were getting type-punned pointer warnings
(errors if CHPL_DEVELOPER is set) from
comm-gasnet.c. It turns out that the code
actually was type-punning. This patch fixes
the type-punning using memcpy. The consensus
among the Chapel developers is that fixing
the problem with a 'union' is a better
solution, but we have a tested patch for
the memcpy version... and a good compiler
should turn the memcpy into a load or store
in any case.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20129 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adds support for -r for retry failing tests, -c gasnet for gasnet tests.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20130 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add config consts to disable running of kernels 2, 3, & 4 of SSCA2

Added config consts to disable running of kernels 2, 3, & 4 of SSCA2.
FYI, kernel 3 require kernel 2.  While I was in there, I reformatted
SSCA2_driver.chpl since the indenting was kinda messed up to begin
with.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20131 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Steps toward LULESH unification and determinism

This change reduces the differences between our versions of lulesh
that use structured and unstructured data structures using 'diff'.
The changes involve minor things like unifying names, spacing, and
tabbing; intermediate things like compiler flags and output format; as
well as more major things like creating iterators to mimic arrays.
The goal is to take a step toward a version that can switch between
structured or unstructured data structures with a command-line flag
(though I haven't gotten there yet).

Perhaps more importantly, this change fixes the nondeterminisms in
forall loops for the original version that we caught in the release
version just prior to the 1.5 release but hadn't folded back into the
original version.  This should remove the nondeterministic failures
that we've been seeing for some time now in LULESH.

Next steps: Work on restructuring the two versions so that all
data-structure-related differences are factored into different
modules or files.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20132 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing a few lulesh commit problems

Standard "duh" stuff:

- forgot to check performance testing after my commit
- forgot to commit a few files that were in my directory but not added,
  so local testing worked -- one dials down the problem size, the other
  indicates the new file that's used by default for array output



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20133 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix filtering bug and turn on filtering for SSCA2 kernel 4

[Reviewed by gbt]

Fixed a filtering bug where edges were being added to next level even
if the edge was filtered out.  This bug has been present since we
first got the code.  This did not affect the correctness of our
nightly test runs since we had filtering turned off by default.

While I was on the topic, turned on filtering by default as required
by the SSCA #2 spec.

Updated .good files to match the results of the change.  For the comm
diagnostics test, most of the comm counts decreased.  In one case
there was a small increase in number of non-blocking forks.  This is
not unexpected as filtering edges could results in more iterations
during the forward pass.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20134 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added graph I/O to SSCA2 in test/release/examples.

This is mostly the code from studies/ssca2/graphio.

Graph I/O can be used by setting these config string constants:

    graphInputFile
    graphInputDStyle
    graphOutputFile
    graphOutputDStyle
    graphVerifyFile
    graphVerifyDStyle

* If graphInputFile != "", read in the graph from the files with
  that prefix; do not run edge generation or Kernel 1.
  Otherwise, if graphOutputFile != "" then write out the graph
  generated by edge generation and Kernel 1 into those files.

* If graphVerifyFile != "" and the graph was read from graphInputFile,
  write it out to graphVerifyFile. Could be used for correctness checking.

* The *DStyle strings control the debugging printouts during I/O.
  See interpretDStyle() for details.

* The graph size in graphInputFile must match the SCALE config constant.

The data is stored in 5 files per graph.
The individual files' names are obtained by appending
the following strings to the above file name constants:

  config const VE_FILENAME     = "vertex_edge_info.data";
  config const SV2_FILENAME    = "sv2_snapshot.data";
  config const EV2_FILENAME    = "ev2_snapshot.data";
  config const START_FILENAME  = "start_snapshot.data";
  config const WEIGHT_FILENAME = "weight_snapshot.data";

For a file format summary, see r19646.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20137 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Implement a filtering iterator for SSCA2 kernel 4

[Reviewed by gbt]

This commit adds a parallel iterator that filters edges based on
weight for the RMAT graph and the torus graph implementation used in
the nightly testing.  This iterator replaces a zippered iteration over
edges and weights, and thus avoids visiting the node (via an 'on') if
the edge is to be filtered out.  It also allows us to better hide the
graph's representation of edges and weights.

Note on logistics: The iterators are implemented in the release
version, as they will not be used and thus not affect the version
built in the release directory.  The use of the iterator is
implemented in my staging area.  This set up simplifies the build in
my staging area.

Note on performance:

For multilocale testing, The number of forks is reduced by 5-8% (due
to filtering before 'on') and the number of remote gets is reduced by
~5%.

Scalar performance is consistently better for the new version (8-18%),
but I was testing under different circumstances, so I will keep an eye
on this once it gets promoted to the release version.

Other stuff:

- Updated SSCA_kernels.chpl to match the release version before
  replacing the zippered iteration

- Updated my .compopts file to add new debug flag as per r20098

- Removed NOTEST to enable nightly testing




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20138 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating TRIAGE to a new format


My approach to TRIAGE is "What caused emails to go to the group this
week and how can we stamp those out to reduce noise down to zero?"  To
that end, I took a different approach to the TRIAGE file that sorts
things by issue rather than testing configuration (which is how
REGRESSIONS is organized).  An issue can be a specific benchmark that
causes problems (like lulesh) or a specific configuration that is
noisy (like qthreads).  I tried to capture everything that caused
noise this week, noting who it was assigned to (if anyone), and what
possible explorations might be.  I also sorted things into two general
categories: At the top, things that are continual pains in our side;
at the bottom things that caused noise maybe once during the week but
weren't immediately recognizable (to me anyway) as ongoing problems.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20139 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Promote r20138 to release version of SSCA2

- Promote the filtering iterator for SSCA2 kernel 4
- Update comm diags test output
- Add NOTEST to my SSCA2 staging area



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20140 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Update map.h to get rid of compilation errors due to new (correct) lookup rules in g++ 4.7

[reviewed by gbt]

Followed the g++ suggestion to add this-> to certain method calls.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20141 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating 32-bit testing to run GASNet as well...

In talking about 32- vs. 64-bit locale ID issues in the LTS meeting
this week, there was a question about whether cases that I'd forgotten
to update would work worse on a 32-bit linux machine.  We haven't been
doing 32-bit linux + GASNet testing, but it seems like a good idea,
so this adds it (for example directories only).



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20142 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added size method to: array, domain, string, and range. 

The size method is simply an alias to other methods in these structures (i.e. 
length, numIndices, numElements).

Adding the size method was done in an attempt to unify, in a more generic way,
the notion of "maximum number of iterations", as per an email discussion
on chapel_dev list, subject: "consistent naming", June 7-8, 2012. 


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20143 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing pvm and armci from the release

I've had this change in my directory since the 1.5.0 release.  After
building the tarball, I realized we weren't blowing away some of the
comm layers that aren't up-to-snuff from the release tarball.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20144 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding a de-tupling bug related to size mismatch

This is an existing bug I stumbled across in getting ready to commit
my 1-tuple change.  The problem is for cases like this:

   var t = (1, 2, 3);

   var x, y: int;

   (x, y) = t;

we should generate an error indicating that the size of t doesn't match
the number of components into which it's being de-tupled, but we don't
and additional components are just silently dropped on the floor.

I suspect this would be quite easy to fix, but I didn't want to get
sidetracked.  I put some clues in the .future file that might be
helpful for getting started on this.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20145 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Improved support for 1-tuples in Chapel

[reviewed by vass]

Prior to this change, 1-tuples could only be created in Chapel by
using the tuple() function with a single argument expression -- i.e.,
tuple(x).  This commit adds support for the syntactic construct '(x,)'
in the expression context to indicate a 1-tuple.  Note that in this
commit, the trailing comma is only permitted for 1-tuples, not for
larger tuples -- i.e., (x,y,) is a syntax error, not a 2-tuple.

Because we most recently were using blank tuple dimensions as a means
of dropping tuple components on the floor, this change also includes
switching back to using underscore for this purpose.  That is, if I
want to get the second component of a 2-tuple, I could have used:

     var ( ,x) = t2;

whereas now I have to use:

     var (_,x) = t2;

This means that _ is no longer a legal identifier by itself and is now
a parser token.

I originally tried to get 0-tuples working in this commit as well, and
got them so that they could be parsed and stored and codegened, but
they weren't all that useful/robust.  E.g., I believe I/O on them
didn't work.  My impression was that in order to implement them
robustly, we'd need to change varargs functions to accept 0 arguments
and return a 0-tuple (which may be a great idea, but was more than I
was able to tackle here).

One last-minute question that came up was that in declaration contexts,
one-tuples without dangling commas are not ambiguous.  That is, while
(x) in an expression context is simply parenthesization (and therefore
can't be considered to create a 1-tuple), in a declaration context like:

      var (x) = t1;

or:

      proc foo((x)) { ... }

The dangling comma is not required to interpret it as a 1-tuple.
After some debate, the decision was to permit these forms due to a
combination of permissiveness, a sense that it wasn't likely to be an
issue (and that we could always reconsider later if it was), and
because it's what was already implemented by the time the question
came up.


TODO: tuple() and build_tuple() are now defined identically; and it's
      no longer clear that tuple() is a useful function since its main
      value previously was to create 1-tuples.  To simplify the
      language, should we remove the user-oriented tuple() function and
      keep build_tuple() as an internal function?  Or if we want to
      keep supporting tuple(), retire build_tuple()

TODO: I need to make more spec updates to define underscore as a token
      and to describe the 1-tuple changes


File-by-file description:

added underscore to chapel.lex and refactored grammar to support
1-tuples (and, commented out, 0-tuples)
----------------------------------------------------------------
parser/chapel.lex
parser/chapel.ypp


added build routine for 1-tuples; also added initial support for
0-tuples added but commented out; refactored buildParenExpr to
pass 0- and 1-tuples through
----------------------------------------------------------------
include/build.h
AST/build.cpp


redefine _build_tuple(x...) to stop special-casing 1-tuples; the
compiler no longer calls it in this case.  Note that _build_tuple() is
now identical to tuple()
-------------------------------------------------------------------------
modules/internal/ChapelTuple.chpl


added case to handle 1-tuples in buildPromotionWrapper()
--------------------------------------------------------
resolution/wrappers.cpp


move away from using blank dimensions to drop tuple components on the floor
---------------------------------------------------------------------------
modules/standard/Sort.chpl
spec/Tuple.tex
test/*




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20146 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Resovled ref type issue (under gasnet) in my size test.

Seg fault occurs on arrays of type real or imag.  Thus, for the purpose of my
size test, I changed all these arrays to be of type int.  It now works as 
expected under gasnet.  I added a new future which covers array declarations
of several dimensions of every primitive type. 


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20147 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Missed .good and .skipif for refTypes test on previous commit.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@20148 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Corrected my future confusion. 

Previous future is now chpl source and contents of new future file now
classifies the test and offers a brief description. 


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