Add vanilla intel cc testing for knc.

It just tests that make succeeds. It makes no attempt to actually compile or run a program...
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.
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
Merge pull request #263 from ronawho/qthreads-as-default

See the performance implications of qthreads without hwloc
Merge pull request #265 from gbtitus/hwloc-1.9.1-is-default

Switch to hwloc v1.9.1 as default.

Reviewed by @bradcray, @sungeunchoi, @ronawho over email.
Wordsmithing based on gregs review
Merge pull request #260 from ronawho/qthreads-syncvar-deadlock

Add real comments to yields in qthreads sync var lock and unlock

[reviewed by @gbtitus]

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.
Convert old way to turn off guard pages to the new way

We used to turn off guard pages for qthreads only by setting
QT_GUARD_PAGES=false. We have a compiler option that allows us to set the
default now and the environment variable for that will eventually be used as a
runtime backing as well. This option turns off stack checks for "all" tasking
layers. Or at least it's intended to, it still only does anything for qthreads,
but it will affect other tasking layers in the future.

I decided to use CHPL_STACK_CHECKS instead of --no-stack-checks because this
way you only have to add one thing to the execenv, rather than add
no-stack-checks for every compopt.
Copy the execopts of stress to stress.numthr

These two test are supposed to be the same and the variations exist because we
don't have a way to specify a different execenv for one test. Without this
change stress.numthr was segfaulting with qthreads because it was trying to
create way too many threads at once. This test didn't segfault for fifo because
only so many tasks (pthreads) could be created at once so the system didn't run
out of memory. With qthreads places no limit and thus with too many tasks at
once we run out of memory and segfault.
Turn off guard pages for stress/deitz/test_10k_coforall

I see this test timeout sometimes when I do a paratest when other people are
also testing. It creates a lot of small tasks so it makes sense to turn off
guard pages for it.
Revert "Convert old way to turn off guard pages to the new way"

This reverts commit 14fd7ba8a9e19fad5ecc450621dabe0ee120d705.

As I should have noticed by the name execenv applies to execution time only and
right not CHPL_STACK_CHECKS only backs the default set by the compiler, and
doesn't affect anything at runtime.