First cut at script that converts start_test log to jUnit xml report.
python 2.6 arg parser
Open logs with utf-8 encoding. Ignore invalid characters.
Fix bug when finding blocks.

If end was not found (-1) it was still added to the start value, which gave a bad end value.
Support jUnit xml style reports in start_test.

Add --junit-xml argument. When set, start_test calls new script to convert
logfile to junit xml style report. Also add --junit-xml-file argument, which
implies the --junit-xml argument. When --junit-xml-file is set, its value is
passed along to the conversion script as the junit xml output file.
Add jUnit XML report generation support to nightly.

Add -junit-xml flag to nightly that add --junit-xml flag when calling
start_test. The flag is thrown by default when JENKINS_URL is set in
environment (i.e. nightly is running inside jenkins job).
Filter invalid XML characters and wrap system-out in CDATA tag.
Add DEBUG setting.
Fix bug that showed up in linux32 logs.
Merge branch 'master' of https://github.com/chapel-lang/chapel into junitxml-for-start-test
Add TODOs based on @Kyle-B's review.
Drop noperf tests, instead of skipping them.

When running performance tests, there are lots of tests that are skipped
because they do not have the performance configuration files. They should not
be included in the jUnit reports as they are not interesting data points. Real
performance tests that are skipped due to the environment/etc are still
included as skipped in the report.
Fixed an issue in handleCaptureArgs()
Support suppressions when generating jUnit reports.
Remove todos.

Suppressions are now supported and multiple performance trials were already
being collected.
Pipe suppressions through start_test for jUnit reports.
Merge branch 'master' of https://github.com/chapel-lang/chapel into junitxml-for-start-test
Change range's 'by' functions for param strides

We have versions of 'by' that take the stride as a param in order to check at
compile time if the stride was 0 rather than waiting until runtime. However
this means that for all non-zero param strides a new function is stamped out
which adds bloat to the generated code. This just adds a "where step == 0"
clause to the functions so that we still get the compiler time warning without
stamping out a function for valid param steps.
Merge pull request #1027 from ronawho/change-range-param-by-funcs

Change range's 'by' functions for param strides

[ok'd /suggested by @bradcray in pr: 1021]

We have versions of 'by' that take the stride as a param in order to check at
compile time if the stride was 0 rather than waiting until runtime. However
this means that for all non-zero param strides a new function is stamped out
which adds bloat to the generated code. This just adds a "where step == 0"
clause to the functions so that we still get the compiler time warning without
stamping out a function for valid param steps.
Initial attempt to optimize anonymous range iteration

When iterating over a range such as:
  for i in 1..10 do ...

we end up constructing a range and then getting it's low and high values out.
The range creation adds additional overhead that is not needed and it
obfuscates the loop from the backend compiler (it probably can't figure out how
the number of iterations even though the chapel compiler knowns it at compile
time.)

Ideally we want to generate
  for i in 1..10
as
  for(i=1; i<=10; i+=1)

This removes the construction cost, and should allow the backend compiler to
optimize/auto-vectorize better.

To accomplish this, this work replaces anonymous ranges with direct iterator
calls in for loops. Ranges are iterable because they have a these method. This
replaces the range with a direct call to an iterator. It essentially replaces
the code:
  for i in 1..10
with:
  for i in _opt_range_iter(1, 10)

the end result is that
  for i in 1..10
is now generated as:
  int64_t i;
  for (i = INT64(1); ((i <= INT64(10))); i += INT64(1)) {}
which is exactly what we wanted

This also handles anonymous ranges whose stride is known at compile time

E.G it handles
  for i in 1..10 by 2

and it will call into a more optimized iterator

if the stride is not known at compile time we don't do anything because we need
the range iterator to use chpl__diffMod

Not that this does nothing for aligned ranges, and doesn't handle cases such as
for i in 1..10 by 2 by 2 since it doesn't seem like a common case

The first attempt to do this was to replace the entire for loop with a c for
loop directly, but you can't do that for zippered iterators and figuring out
the type of the stride is really difficult and you have to insert calls to the
overflow checking and the general iterator.

A better long term solution might be to expand scalarReplacementOfAggregates to
includes ranges. That would allow all ranges to be optimized, including
non-anonymous ranges, and ranges that are used in contexts other than direct
iteration.

I still need to clean up the direct iterators, and make use of them from other
iterators. I also need to add bounds checks and the general iterator around it.