Removing files from my lulesh variation

* I svn cp'd Sung's LULESH directory, which caused conflicts in our
  performance testing, which is why performance tests have failed the
  past few nights.  Oops, sorry.

* Removing the sedov15cube.lmesh file now that I've put a new version
  of it (and others) in the ../lmeshes directory



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19740 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Renamings and other mods to I/O based on the Chapel group review; UTF-8 bug fixes. 
 
Thanks to Vass for reviewing these changes.

* Renamed:
 iomode.w -> iomode.cw
 iomode.wr -> iomode.cwr
 HINT_CACHED -> IOHINT_CACHED and other HINT_* -> IOHINT_*
 err_t -> syserr
 defaultStyle() -> defaultIOStyle()

* modifyStyle() is no longer provided.

* read/readln(type tuple) now one function instead of two.

* Added
 qio_quote_string()
 qio_quote_string_chpl()

These are for use when one can't use a channel
because it is prior to the I/O module initialization,
e.g. for quoting filenames in error messages.

* The standalone read/readln(args...) now return a bool indicating success.

* Brad's suggested changes to I/O error format, including quoting the
filename.

* 'inout error' -> 'out error' in a few functions.

* Adjusted the IO primer and other tests.

* Fixed some UTF-8 bugs.

* Other minor I/O cleanup.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19741 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Filing QIO tests and futures from pair programming with Jeff yesterday

* readArr.chpl is a cute idiom that Jeff and I tried yesterday, and
  were surprised to find works.  It is a standalone function that
  reads an array size and then creates the array, reads it, and
  returns both the size and the array itself.  The callsite uses type
  inference to declare the array without having any idea how large it
  will be.  Pretty fun.  (Note for performance-minded programmers,
  programs with many arrays of the same size, this approach will have
  the downside of creating a domain per array which will cost space
  and thwart the compiler's ability to reason about the arrays being
  the same size)

* readWholeArr is an unimplemented feature future showing that
  whole-array reads don't work in QIO, just as they didn't work
  in the old I/O scheme.

* readTuple demonstrates what I'd consider to be a bug -- though QIO
  supports reading a type, it seems that type can't be a tuple type.
  (The .future also shows a workaround for people who want to do
  this).



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19742 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Make the default distribution type used for the distribution
robustness tests BlockDist if CHPL_COMM!=none.

This change sets the default distType to be DistType.block if the comm
layer is not none.  This means that we won't be testing the default
distribution on a nightly basis, but we thought that would be fine
since default gets good coverage over the entire test suite.  This
mean that the multilocale test suite used in nightly testing will now
be testing something more meaningful.

I also had to change a couple of prediffs that wrote .good files based
on the distribution used.  They now check CHPL_COMM before assuming a
default distribution type.

FWIW, I noticed that using CyclicDist with CHPL_COMM=none fails for
reindexing/test_strided_reindex2.chpl because it gets a different
error than the one expected with CHPL_COMM=gasnet.  The test expects
an error, and since we don't run this variant nightly, I just let it
be.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19743 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Committing a couple of futures related to EOF

Michael noted on email today that he was aware that there
might be problems related with checking that we're at the
EOF for a reader channel, but didn't have a test case that
captured it.  lulesh-eof.chpl is a case that fails regularly
for me.  It tries to assert that we're at the end of a file
after we've consumed the whole thing but triggers an internal
error in QIO.  The output generated by the debugIO flag
indicates that we have consumed the whole file.

The lulesh-eof2 test is a feature request that a channel
might support such a capability by default to save the user
the (minor, but annoying) pain of writing such a routine
themselves (I know I put it off for several hours, only
to have it bite me when I wasn't at EOF as I expected to be).

Both of these tests could be retired once working by folding
the resulting capabilities into lulesh.chpl.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19744 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Oops... Hadn't updated to Michael's QIO updates, so was still using err_t

Fixed here.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19745 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Got unstructured LULESH into a testable state and cleaned some things up

At this point, lulesh.chpl is testable; note that the identical
problem as Sung's version takes too long to run at present in this
version, so I'm running on a smaller (and unstructured, just to
exercise that) problem size.  Output is verified by using the number
of steps as a checksum and the location of the coordinates (which
hopefully will be stable now that we've converted race-y reductions
into real ones.

Other changes in this version include:

* changed defaults of some of the config consts

* changed default filename to a medium-sized unstructured case

* fleshed out missing debugIO checks (oversight yesterday)

* removed ranges over Elems and Nodes because they were unused

* renamed ElemDist and NodeDist to Elems and Nodes because I don't
  really like using the "Dist" names throughout the code.  Have
  checked with Jeff on whether he's cool with these names

* removed Eid, Nid, which neither Jeff or I like much, replacing
  with index(Edges), index(Nodes).  (Have also proposed creating
  "Edge" "Node" typedefs, but am waiting for Jeff before taking
  that one on).

* updated to match recent QIO renamings

* made benchmark always print out number of cycles for now, since
  this is such a useful value (as a checksum, just for curiosity)

* changed dump of coordinates to go to a file

* unified output format of dumping coordinates for debug and
  production runs using a cute string variable trick.

* fixed a lame commented out line in readNodeset that we added
  yesterday in a fit of paranoia.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19746 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding some commDiagnostics tests to the distribution robustness suite.

These simple tests were motivated by SSCA2 performance bottlenecks.
They cover reduction and whole array assignment of like distributed
arrays in the case of slicing, aliasing, vanilla.

.good files have been generated for block, cyclic, replicated, and
none.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19747 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove default .good files and add CLEANFILES.

I accidentally committed default .good files for these tests.  The
PREDIFF should be writing the appropriate .good file for each test.

Added a CLEANFILES to remove default .good files.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19749 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Didn't notice that I should've removed this file to clean up lulesh
perf testing



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19750 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding a future for a function resolution bug.

This is a stripped down version of the tests committed by Vass in
r19625.  If a distribution is used in a non-top-level scope *and* the
distribution module declares a domain that is dmapped using that
distribution, the compiler does not properly resolve the type
constructor for the distribution (and prints no candidate notes).

The tests committed in r19625 were originally categorized as module
search path bugs.  What probably contributed to the confusion is that
when we add the new type constructor to the AST, we do not properly
update the filename/linenumber and so they are basically set to
something randomish.  Thus the error message is really confusing.  I
have a one-liner to fix this, which I'll commit soon (testing now to
make sure it doesn't mess up any line numbers elsewhere).

We should probably either update the futures committed in r19625 (and
possibly move them to a more appropriate directory) or we could just
delete them.  I'll leave that up to Vass.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19751 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Moving my no_use_BlockDist.chpl test from the trivial directory to my
new distributions/sungeun/misc directory.

Seems more appropriate.



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

- many new gasnet timeouts now that robustness tests have been switched
  to use block -- particularly for qthreads and nanos, but also for
  normal; worse, they're nondeterministic (as you'd expect)

- fileIO test fails on darwin (not sure why yet)

- my new lulesh seems to have some nondeterministic numerical stability
  under gasnet testing; also still causing performance testing failures
  (this latter one should now be fixed)

- 3 new distribution robustness tests fail under gasnet (should now be fixed)

* normal nondeterminisms



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19753 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Filing a bug against overloading a function with an array

This is a bug that Jeff and I ran into last week which surprised me.
Defining a function and array at the same scope doesn't cause a
conflict, and causes the array to be chosen.  In this .future, I'm
proposing it should be an error that's caught at scope resolution
time, much as defining two arrays with the same name would.  Could be
a candidate for a 5-minute fix (TM).



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19754 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add SET_LINENO() call for type constructor.

Added SET_LINENO() call so that the new call expression for the type
constructor is in the same place as the default constructor.

Found this when looking at the distribution type constructor future I
just filed.  The line numbers for the type constructor are more or
less random without the call to SET_LINENO().



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19755 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Promote my latest working version of SSCA2 kernel 4 to the release
directory.
 
- Clean up and promote the changes from r19673 and r19722 to the
  release version:
  - Fix 'on' bug (r19673)
  - Locale and task private variables (r19673 and r19722)
  - Slice the children_list rather than resizing (r19722)
  - Add inline methods for assigning the task private variables
  - Move all auxiliary data structure to the end of the module

- Update to the commDiagnostics performance test to reflect the
  current communication counts (much lower!!!!):
  - Fixed the precomp test to deal with reorg of procedure declarations
  - Update the prediff file and the .good file

- Add a NOTEST to my staging area as SSCA2_kernels.chpl is the same as
  the release version.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19756 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removed an \mbox{} that was added to push a sentence to the next page.
(It is no longer useful because pages have shifted.)


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19757 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Started implementing the suggestions from the 2/21 spec review of the "Input and Output" chapter.

Includes reflecting some of the changes to the code by Michael through r19741,
and suggestions from Tom and Brad.

Also minor clean-ups.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19758 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Changing memory tracking to always be run-time-determined.

From r19641, Chapel memory allocation/free routines
were made inline, but that also precluded using
--memTrack in a runtime built with CHPL_OPTIMIZE.

This patch makes the default to check if --memTrack
was specified at run-time; a user could always build
a runtime with -DCHPL_MEM_DEBUG=0 if they really care
about the slight (5%) performance hit here.

Before this change:
Chapel Native Allocation
Allocating and freed 100000000 3.243774 s
tc malloc Allocation
Allocating and freed 100000000 3.281344 s
tc calloc Allocation
Allocating and freed 100000000 3.267766 s

After this change:
Chapel Native Allocation
Allocating and freed 100000000 3.390768 s
tc malloc Allocation
Allocating and freed 100000000 3.290613 s
tc calloc Allocation
Allocating and freed 100000000 3.249387 s

The test memstatPrint updated because it
now includes tracking allocations in the runtime.

Reviewed by Greg.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19761 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add text logging capability.

On the command line, add --log=<letters> or -d<letters> to log the AST at the
end of the corresponding pass.  Pass letters are defined in log.h.  Using -d or
--log without any pass letters specified logs the AST output for ALL passes.

For each pass, output is written to a file of the name:  <module-name>_<pass-name>.ast
Output is placed in the ./log directory by default.  
Use --log-dir=<path> to specify a different directory.
Use --log-module=<module-name> to narrow the dumping to a single module.
Use --log-symbol=<symbol-name> to narrow the dumping to a specific symbol name.
Use --log-ids to cause node IDs to be inserted into the AST dump.


Details:

The former use of log.h was obsoleted and removed from ifa_vars.cpp.

In log.h there is now a #define LOG_xxx, for each pass, where xxx is the pass
name as specified in passlist.h.  The value of these #defines is a mnemonic
character which is used to select that pass in the --log= command-line argument.
The special value NUL is specified for passes which are expected to be of little
interest to the developer (e.g., the "check???" passes).

The concept of a log level was removed.  In the previous implementation,
specification of a log letter multiple times would select a higher level of
logging, but this feature was unused.

The log flags specified by the user are private to the log module.  The value of
a particular flag is tested using the logging(int) function, whose argument is
the name of one of the #defines in log.h.

The #defines for the FIRST, LAST and RUN macros were moved inside passlist.h.

Comment indentation was adjusted in passlist.h.  The second invocation of
"prune" was renamed as "prune2", so that each pass has a unique name.  This is a
new restriction on pass names, made necessary because each non-NUL pass letter
must be unique, coupled with the fact that the RUN macro takes only one parameter.

dump_ast() and its supporting routines were derived from html_view().


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