Add a .skipif to meteor-parallel-alt for when CHPL_TARGET_COMPILER contains pgi

[verbally reviewed by bradc]

meteor-parallel-alt uses the gcc intrinsic __builtin_ctz (count trailing
zeros). This call should eventually be replaced by our bit operations library,
and the skipif should be removed at that time.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22568 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
source /etc/modules/bash before calling module command.

r: sungeun

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22569 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove TODO and commented job from bradc-lnx cron config.

r: bradcray

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22570 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix typo in cron warning message.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22571 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Filter comments and blank lines from cron output in emails.

r: vasslitvinov

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22572 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Update svn repos at 20 past the hour to accomodate mirror sync.

The mirror updates at 15 past the hour.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22573 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Allow casts between c_ptr types and allow c_ptrTo on arrays.

[reviewed by Tom]

This patch enables casts (by providing a _cast proc) for
c_ptr types and also creates a special version of c_ptrTo
for arrays that checks for a 1-D rectangular arrayand
returns a pointer to the first element.

I also changed the name of the extern function c_ptrTo
to _c_ptrTo so that c_ptrTo is the version with the extra
checks (that normally just calls c_ptrTo which just returns
the original pointer anyway).

Future work: better error handling for c_ptrTo and doc updates.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22574 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add support for a "minimal modules" compilation mode

[reviewed by Kyle and partially by Greg]

This commit adds support for a developer flag, --minimal-modules, in
which Chapel programs are compiled with a minimal amount of internal
and standard module support.  This means that the language will be
virtually crippled (since so much of Chapel is defined within
modules), but it permits a developer to work on compiler
transformations in the core of the language without having to worry
about getting all of the internal/standard modules to compile properly
before evaluating their result.

As an anecdote, I've been wondering recently about changes to the way
we (1) represent ref intents and (2) implement assignments within the
compiler, but in changing either concept, it can take so long to work
through all of the issues that arise in the internal modules that it's
hard to determine whether I'm making progress or not.  With the
--minimal-modules flag, I was able to make a simple change to the
compiler to try issue 1 above and see its impact on the generated code
without wrestling through all of the issues that would have arisen
using the full set of internal modules.

Of course, in some sense, this is just postponing the inevitable, but
the hypothesis is that it enables you to see that you're making a
correct/reasonable change earlier than you might otherwise be able to
determine if you were compiling the normal modules in full.  Over
time, it may also be a means for us to determine which parts of the
internal/standard modules are particularly brittle or antiquated
w.r.t. the current language definition/compiler architecture, and
make them less so.

The general strategy here was to make a clone of modules/internal
(called modules-minimal/internal) and then to rip out all but the most
essential components.  When compiling with --minimal-modules, we use
that clone rather than the normal modules.  The intent is that the
minimal-modules directory will not be bundled in the release since
it's a developer feature and just adds clutter to the top-level
directory.

One design decision was to avoid changing the interface between the
runtime and compiler-generated code/modules in order to avoid having
to maintain different builds of the compiler when using
--minimal-modules vs. not.

What remains in modules-minimal are six modules that correspond to
their full-blown counterparts, and make the following definitions:

  ChapelBase.chpl:
    - proc =()            : in its most generic form
    - _ref                : the standard ref class/type mechanism
    - chpl__initCopy()    : in its most generic form
    - chpl__autoCopy()    : in its most generic form
    - chpl__autoDestroy() : in its most generic form

  PrintModuleInitOrder.chpl: expected by the compiler, but empty here

  ChapelStandard.chpl: expected by the compiler, now use's the next 3 modules:

  ChapelTaskTable.chpl:
    - chpldev_taskTable_*()    : called from the runtime, all no-ops now
  
  MemTracking.chpl:
    - chpl_memTracking_returnConfigVals() : called from runtime, now a no-op

    ** One important note here is that, in order to avoid bringing in
       SysCTypes.chpl along with everything it requires, I hard-coded
       some arguments that are actually size_t to be uint(64) which is
       a non-portable solution, but probably sufficient for most
       developers to use (the audience for this patch) and unlikely to
       cause any significant problems given that the function is a no-op
       anyway.  If this does give anyone hassles, let me know and we
       can consider other options.

  ChapelUtil.chpl:
    - chpl_main_argument       : the argument type passed to chpl_main()
    - chpl_rt_preUserCodeHook  : a call into the runtime prior to user code
    - chpl_rt_postUserCodeHook : a call into the runtime after user code

The effect of taking everything else out is that none of Chapel's more
exotic types which are defined using modules are available (i.e., no
ranges, domains, arrays, tuples, sync/single, atomics).  As a result,
parallelism is similarly unlikely to work (since it relies on
synchronization types internally).  Similarly, basic/core operations
like +, -, *, /, ... casts, etc. are not defined due to their reliance
on module code.  

Naturally, a developer can incrementally add such functionality back
to their copy of modules-minimal, or to a specific test, but it won't
be included by default (for fear of there not being a clear place to
draw the line).


Apart from the modules themselves, here are the changes involved, by
file:

runtime/src/chplmemtrack.c
--------------------------
as mentioned above, the routine in MemTracking.chpl is now a no-op, so
I changed the initializations of some variables here so that they'd
have legal/appropriate values whether or not this routine did anything.


compiler/util/files.cpp
-----------------------
made the module search path switch between 'modules-minimal' and
'modules' depending on whether or not --minimal-modules is thrown.  I
made all of the normal search paths use this same base directory, even
though most of the subdirectories under modules-minimal don't exist.
My rationale was so that if a developer wanted to replicate some of
the other module files in their usual subdirectories it would be easy
to do so.  Ultimately, we may want the ability to specify a root
module directory via a compiler flag, but I didn't go that far here.


compiler/include/driver.h
compiler/main/driver.cpp
-------------------------
added the new --minimal-modules flag and an fMinimalModules global to
store its state


compiler/main/config.cpp
------------------------
when compiling with --minimal-modules, stubbed out the checks for some
standard configs because they're not defined in this mode


compiler/passes/filesToAST.cpp
------------------------------
when compiling with --minimal-modules, stubbed out the error thrown if
we don't find standard module-defined types like _array, _tuple, etc.
because they're not defined in this mode


compiler/AST/astutil.cpp
------------------------
protect 'object' from being dead-code eliminated.  The compiler relies
on its presence, but usually it gets preserved automatically through
the creation of classes in the internal modules.  Now that we don't
create any classes there, we need to special-case it.


compiler/passes/buildDefaultFunctions.cpp
-----------------------------------------
when compiling with --minimal-modules, don't deal with endcounts in
main() (because it relies on synchronization types that aren't
supported in this mode); and don't create default I/O routines for
records (because QIO isn't supported).  The former is a necessity; the
latter is probably just a case of avoiding pointless work (i.e.,
I'm guessing it wouldn't hurt to re-enable it, but didn't bother
trying).


compiler/AST/astutil.cpp
compiler/passes/addInitGuards.cpp
compiler/resolution/functionResolution.cpp
---------------------------------
when running with --minimal-modules, I stubbed out the code relating
to printing the module initialization order for simplicity and fear
that it relied on QIO.  Turns out that it doesn't relate to QIO (I
think) and probably could be re-enabled, but the simplicity argument
still sticks.  If the routine doesn't exist (and it doesn't when
compiling with --minimal-modules), gPrintModuleInitFn will never be
assigned, so these files now stub out the related actions when it's
NULL.


test/compflags/bradc/minimalModules
test/compflags/bradc/minimalModules/minModDeclPrint.good
test/compflags/bradc/minimalModules/minModFnRefArg.chpl
test/compflags/bradc/minimalModules/COMPOPTS
test/compflags/bradc/minimalModules/minModFnRefArg.good
test/compflags/bradc/minimalModules/minModDeclPrint.chpl
---------------------------------------------------------
added a few tests that I used while developing this, just to lock the
behavior in, should the key interfaces change




git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22575 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added a CLEANFILES.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22576 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix broken crontab piping.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22577 3a8e244f-b0f2-452b-bcba-4c88e055c3ca