Initial pass to switch from CHPL_MEM value of 'default' to 'cstdlib'
Merge branch 'default-to-cstdlib' of github.com:benharsh/chapel into default-to-cstdlib
Renaming files to match cstdlib naming; Correcting naming in docs
Update the cygwin entry slightly
Add overflow checks to bounded iterators

The default iterators do not support positively strided ranges whose last index
is max(indexType) or negatively strided ranges whose last index is
min(indexType). E.G "for i in max(int)-10 .. max(int)"

The above example turns into the following generated code

for (i=max(int)-10; i < max(int); i+=1)

and everything is less than max(int) so you would have an infinite loop.

Prior to c for loops our iterators didn't work for maximal ranges, but they did
work for the above example. They generated the equivalent of:
for (i=max(int)-10; i != max(int)+1; i+=1)

This relies on well defined integer overflow, which is not valid since integer
overflow has undefined behavior in c.

So while the new iterators aren't as capable as the old ones, they're more
performant, and don't cause undefined behavior.

To deal with this limitation I added a function that checks for overflow and
halts with a warning about them.

If a user really wants to iterate over such a range, I added a generalIterator
that works for any range including maximal ranges, but is terribly slow. To
avoid the performance cost the user can either rewrite their loop to avoid the
problem or try a wider type if they aren't already at the max size.

If they don't care about performance they can toggle
useOptimizedRangeIterators=false which is a big hammer that will use the slow
general iterator for all cases. This will lead to absolutely awful performance.
I can't think of a way to support such ranges in an optimal  fashion, but there
may be a better way to let users pick and chose what loops use the general
iterator.

The general iterator exposed some bugs in the c for loop implementation. Namely
that the break and continue labels were getting added to the wrong structure.

There are also some tests changes.

trivial/deitz/test_max_range_iteration
types/range/hilde/maximalRange

were tests that has ranges that the new iterators do not support. I updated
these tests to include the new error. I also added compopts so they tests the
unoptimized iterator. With bounds checks off and the optimized iterators being
used these tests would have infinite loops. We break to avoid this, so one
variation of the test captures the fact that these infinite loops will occur
(and are expected, although unfortunate.)

I also added a test that checks similar behavior as the previous two tests but
it does it for unsigned and signed variations for positively and negatively
strided ranges.
Need to cast stride.

The stride needs to be casted when the idxType is unsigned. This is still
correct even if the stride is negative because val:uint + -val2:uint is the
same as val:uint + max(uint)-abs(val2)+1

E.G. 1:uint + (-1):uint ends up being 1 + 255 which will end up being 0 since
unsigned integer overflow is well defined
Change bigStride to prevent overflowing

[ok'd by brad]

Quote from brad:

"Re-reading the history of this test, it was basically guarding against
some assumptions in the early range code that the idxType and/or stride
were 32-bits.  I think as long as the stride for this thing can't be
stored in an int(32), my earlier self would be happy.  For example,
maybe something like:

  1..2*(n/3) by n/3

(with some +/-1's in there to get a few values without hitting the
overflow issue?).  I can take this if you want."
Change atomictest to prevent range iterator overflow

[ok'd by brad]

quote from brad:

"Elliot says he doesn't think this is a particularly compelling example,
which I'd agree with.  We can just set n to be something smaller. "
Change fannkuch-redux-blc.chpl to use an unbounded range

This is identical to what brad did to the other fannkuch versions in
0b09c9534e5ef7bfabdd6040f76b1e4ea817a320

Just changing this test as well
Cast histoSerial iterator indices so they don't overflow the iterator

The iterator attempts to do something like "for 0:uint..length:uint by -1" and
so the last iteration will result in overflow since 0 -1 for uints will
overflow. This just casts the uint32 to int64s to prevent that
Update t2.chpl and t8.chpl to prevent iterator overflow

[ok'd with vass]

These tests create unsigned integer overflow in a couple of cases. They have
things like for 0..9 by -1. This causes overflow for the iterators. This just
changes the bounds to things like 1..9 by -1.
Remove pointer to STATUS for range iterator overflow

I'm not quite sure where the best place to put the note is, but STATUS isn't
quite right. Something about what the behavior of iteration over ranges is
needed in the spec, but I'm not sure if we want to point to that, or if there
should be a technote or something else.
Add a check to ensure that all PRIM_YIELD primitives are removed from the tree after lowerIterators.
Add a new future to quiet recordBug/test_likepy.

Investigation of this bug shows that recursive iterator inlining is not being done
completely.  It should include translation of PRIM_YIELD primitives, and does not.
Fix typo in .good file
Merge branch 'master' into triage
Merge branch 'quickstart-use-default' into default-to-cstdlib
Using cstdlib in quickstart scripts
Note another instance of the waynew/example2 intermittent failure.
Found another stray default