Add vanilla intel cc testing for knc.

It just tests that make succeeds. It makes no attempt to actually compile or run a program...
Limit the max alloc_size to just over 32MB.

this routine is used to allocate various memory pools. One of those pools
happens to be stack pools, and with our large stack size, we allocate over a
gig per call. This puts an upper limit on the max alloc_size of a somewhat
arbitrary 32MB.

A previous approach was to limit that 128 value and make it user definable
through an env var. But Greg pointed at that this is used for all their pools
and thus an allocation limit rather than a bundle limit is more appropriate.

If item_size is large, we don't want to always try to allocate space for
128 items, so it's limited to 32MB, but if item_size is really large (>32MB) we
want to ensure that space can be allocated for at least one bundle. E.G. if a
user sets stack size to 36MB, we still want to be able to allocate at least one
item, otherwise we'd be in some serious trouble.
Ensure that 'castCall' is not "may be used uninitialized" in wrappers.cpp
Remove debugging prints, change max_pool_alloc_size default

Default max_pool_alloc_size to be proportional to hpwar * callStackSize. See
comments in the source for detail.

Also fixes a strncat bounds
some word-smithing
Merge pull request #256 from vasslitvinov/coercion-wrapper-elimination-build-fix

Ensure that 'castCall' is not "may be used uninitialized" in wrappers.cpp

Vass asked me to review and merge this on his behalf.  There was a warning about a possibly uninitialized variable because of a code path with an INT_FATAL.  It is initialized to NULL in that path now.
Merge pull request #257 from ronawho/qthreads-max-alloc-size

Limit the memory qthreads uses for it's memory pools

[reviewed by @gbtitus]

Qthreads uses memory pools for things like stacks, thread private data, runtime
data, etc. It assumes that the item size for things in the pool is small,
however our default stack size is quite large. This meant that with qthreads we
were allocating over a GB up front.

This seemed to be a real problem on a 32 bit machine, but the real problem
there ended up being the qthreads lowest common multiple routine was
overflowing (which is fixed in this commit.) Still the work was already put in
to limit the amount of memory and it's something we wanted to do anyways.

This approach modifies qthreads to take the max pool alloc size as an env var,
but if always ensures that at least two items can be allocated. Without this
env var set, qthreads behavior is unaffected. Note that Qthreads team has not
formally reviewed this as they're busy this week, but they will next week.

When we're setting up qthreads we set the max pool alloc size to be a multiple
of hardware parallelism and the call stack size, with the idea that memory will
be proportional to number of cores. We set a lower bound on this so we don't
make all qthreads pool allocations limited, and a maximum size on this for
architectures with many cores, but limited memory.
No longer peg call stack size for linux32 box

The issue with qthreads has been fixed with
cee911bf5a2efdeb6ed9753d984a07b0b6d0b78c
Merge pull request #258 from ronawho/qthreads-max-alloc-size

No longer peg call stack size for linux32 box

The issue with qthreads has been fixed with
cee911bf5a2efdeb6ed9753d984a07b0b6d0b78c
Revert "Set runtime stack size to 2M for 32bit platform in smoke test."

This reverts commit bde1b76f1025cd01511b728ec7efe7c620eac92f.

linux32 was fixed by cee911bf5a
Add real comments to yields in qthreads sync var lock and unlock

These were added to resolve deadlock that cropped up when we switched to the
nemesis scheduler. I never commented them properly because we weren't sure it
was the final solution or if the values were good. Things seem to be in good
shape some I'm adding extensive comments.
Merge pull request #259 from thomasvandoren/update-linux32-build-script

Revert "Set runtime stack size to 2M for 32bit platform in smoke test."

This reverts commit bde1b76.

linux32 was fixed by cee911b

requested by @ronawho
Adding future for type mismatch for autocopy functions with ref arg
Merge pull request #261 from sungeunchoi/test

Adding future for type mismatch for autocopy functions with ref arg

bug: Compiler internal error for record autocopy functions that take a ref arg

recordWithRefCopyFns.chpl:25: internal error: actual formal type mismatch for chpl__autoCopy: myR != _ref(myR) [checks.cpp:627]
Unload all craype-intel-knc conflicts for vanilla test script.

suggested by @ronawho
Merge pull request #254 from thomasvandoren/test-vanilla-intel-knc

Add vanilla intel cc testing for knc.

It just tests that make succeeds. It makes no attempt to actually compile or run a program...

reviewed by @ronawho
FATAL error generated from compiler for type int.

Compiler generates a FATAL for the following program

var sum1 = 0.0;
var sum : int = 0;

sum1 = 4.0;
sum = (int)(sum1);

internal error: FUN5894 chpl Version X.XX.X

Compiler treat (int) as a constructor call for int taking
a real argument.  This should generate an error message.
Merge pull request #262 from tmacd9/fatal

FATAL error generated from compiler for type int.

Compiler generates a FATAL for the following program

var sum1 = 0.0;
var sum : int = 0;

sum1 = 4.0;
sum = (int)(sum1);

internal error: FUN5894 chpl Version X.XX.X

Compiler treat (int) as a constructor call for int taking
a real argument. This should generate an error message.

[reviewed by diten]
Switch to hwloc v1.9.1 as default.
See the performance implications of qthreads without hwloc