In iterator.cpp convert uses of the blockInfo type with tests on the BlockStmt
Fix for Coverity defect 1219940.
Convert a test on blockInfo state to an explicit test on a Loop
Fix increased leaks in domainsMaps test due to #860.
Update chown/permission_error test to work, even when uid/gid is 1000.

Previously, this test assumed that calling chown 1000:1000 file.txt was
invalid. That turns out to be valid if the current uid/gid is 1000/1000.

Update the test to take uid/gid as config consts and then add one to both to
get invalid uid/gid value.
Add robustness to parallel pass by adding calls to insertReferenceTemps...

... in places where the called function might take an argument by reference, and therefore
require the insertion of a reference temp.
Update fielderator tests to account for small diff in reals.

These were failing on an Ubuntu 32bit utopic (14.10) system with gcc 4.9.1 due
to a very small (0.00000000000000043) difference between two instances of
17.23.

Update the comparison to find the absolute difference between the two reals and
ensure the difference is less than 1e-8.
Merge pull request #887 from vasslitvinov/fix-coverity-1219940

Fix for Coverity defect 1219940.

Coverity said:

In resolveMove() we have:

  FnSymbol* fn = toFnSymbol(call->parentSymbol);

then we call fn->getReturnSymbol() without ensuring that 'fn' is non-NULL.
Indeed, 'fn' can be NULL - e.g. when 'call' is under a ModuleSymbol.

In practice this defect never fired for us, so this fix is just for Coverity.
While Coverity pointed to a particular occurrence of fn->getReturnSymbol(),
I fixed a couple of other places that I think Coverity could complain about.

* Replaced fn->getReturnSymbol() with 'isReturn', which I compute hopefully
in Coverity-legal way.

* Replaced fn->hasFlag() with call->parentSymbol->hasFlag().
Other alternatives are:
 ** fn && fn->hasFlag() 
    I chose against that to save a branch
 ** leave fn->hasFlag(), hoping that Coverity will realize that
      isReturn ==> fn != NULL
    It is probably not be worth the effort to check what Coverity
    thinks about it.

Mike conjectures that it may be best to separate the logic to handle
fn==NULL from that for fn!=NULL. This might be better done
when we start overhauling resolve altogether.

Reviewed by Mike.
Merge pull request #891 from noakesmichael/iter-0

Several of the section constructors in iterators.cpp are specialized for CForLoop.  Convert these
from a reliance on isCForLoop()

Compiled: STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest
Review: None
Tweak trailing whitespace
Update business logic for isInCForLoopHeader for deadExpressionElimination
Add a bug future for returning records from functions

From return-record.future:

bug: records being returned from functions are not handled properly

There are two bugs here, depending on if the return type from the function is
inferred or not. Both cases should eventually do the same thing.

When the return type is inferred (baz in this test):
  =(...) is not called when assigning to the return variable, and a PRIM_MOVE
  is used instead. This causes a bitwise copy in the generated C, including the
  pointer to a 'helper' instance. So when the local Zed is destroyed on leaving
  the function, the pointer in the returned value becomes invalid.

When the return type is specified:
  =(...) is correctly called in this case, but both the left and right hand
  sides of the assignment are deallocated before returning. Only the right hand
  side should be deallocated.

So we either need to perform the move into the return temp, and not destroy it
before returning (this would be faster, but I'm not sure it if will miss some
edge cases), or we should only destroy the rhs of the =(...) before returning.

To make this bug easier to observe, I recommend setting M_PERTURB (glibc),
MallocScribble (osx), MALLOC_OPTIONS=J (bsd), or whatever the relevant setting
for your implementation of malloc/free is to write a value to any freed memory.
Merge pull request #894 from Kyle-B/kb-add-record-return-bug

Add a bug future for returning records from functions

From return-record.future:

bug: records being returned from functions are not handled properly

There are two bugs here, depending on if the return type from the function is
inferred or not. Both cases should eventually do the same thing.

When the return type is inferred (baz in this test):
  =(...) is not called when assigning to the return variable, and a PRIM_MOVE
  is used instead. This causes a bitwise copy in the generated C, including the
  pointer to a 'helper' instance. So when the local Zed is destroyed on leaving
  the function, the pointer in the returned value becomes invalid.

When the return type is specified:
  =(...) is correctly called in this case, but both the left and right hand
  sides of the assignment are deallocated before returning. Only the right hand
  side should be deallocated.

So we either need to perform the move into the return temp, and not destroy it
before returning (this would be faster, but I'm not sure it if will miss some
edge cases), or we should only destroy the rhs of the =(...) before returning.

To make this bug easier to observe, I recommend setting M_PERTURB (glibc),
MallocScribble (osx), MALLOC_OPTIONS=J (bsd), or whatever the relevant setting
for your implementation of malloc/free is to write a value to any freed memory.
Merge pull request #892 from thomasvandoren/robustify-real-comparison

Update fielderator tests to account for small diff in reals.

These were failing on an Ubuntu 32bit utopic (14.10) system with gcc 4.9.1 due
to a very small (0.00000000000000043) difference between two instances of
17.23.

Update the comparison to find the absolute difference between the two reals and
ensure the difference is less than 1e-8.
Merge pull request #890 from hildeth/recordWithRefCopyFnsTail

Add robustness to parallel pass by adding calls to insertReferenceTemps....



... in places where the called function might take an argument by reference, and therefore
require the insertion of a reference temp.

This just extends the quick-fix for the failing verify test types/records/sungeun/recordWithRefCopyFns to other places in parallel.cpp, so similar errors will not surface in the future.
Merge pull request #895 from hildeth/fixIncreasedLeaksDomainMaps

Fix increased leaks in domainsMaps test due to #860.
Correct typo in cullExplicitAutoDestroyFlags.
Merge pull request #896 from hildeth/master

Correct typo in cullExplicitAutoDestroyFlags.
Merge pull request #893 from noakesmichael/cforHeader

Additional CForLoop refinements

DeadExpressionElimination (removing dead "Statement Expressions") included a step
in which certain expressions were tested by walking up the parent chain to determine if
the expression was embedded in a CForLoop blockInfo.  Convert this test to use the
new tag on BlockStmt.

Also tweak some of the output of AstDumpToNode to squash some of the trailing whitespace.

Compiled STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest --verify
Review: None
Annotate the nights where NPB EP and IS performed better, used -E

I had misinterpretted the desire to use -E as a desire to use it nightly rather
than a desire to maintain default behavior but compare it to tweaked behavior.
Since there isn't a good way to compare them (our execenvs don't allow multiple
settings), decided to just leave the default for now.