Removed a future that is passing due to r22438.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22459 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Factor insertLineNumbers(). [reviewed by Lydia]

Factored two functions -- moveLinenoInsideArgBundle() and insertNilChecks() -- out
of insertLineNumbers().  This change is purely formal.

[tested on primers/ (std)]



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22460 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove nondeterminism from runs of the refcnt test. [reviewed by vass]

The nondeterminism in the output of users/ferguson/refcnt.chpl:
  writeln("Before scope (begin)");
  sync {
    var r:R;
    begin {
      test_one(r, false);
    }
  }
  writeln("After scope (begin)");
was due to calls to chpl__autoDestroy() being inserted after the _downEndCount
call at the end of a begin block.  The autoDestroy calls belong to the "begin"
block, so their actions should be completed before the "begin" block declares
that it is done.  If this condition does not hold, then those actions can "leak
out" of a surrounding sync block.  (And indeed, that is what was being
observed.)

In particular, the destructor for the record type R used in the test calls
writeln, so there is observable behavior associated with when the autoDestroy
call actually runs.  Code following the sync block is enabled as soon as
_downEndCount() is executed.  This introduces a race between that code and and
code which follows the _downEndCount call in [code that was generated from] the
begin block.  So "After scope (begin)" might be printed before the message
indicating that the r inside the sync block is being destroyed.

For the fix, I just forced autoDestroy calls added to a begin block to be
inserted before the call to _downEndCount, rather than after.  Along the way, I
found I needed to flatten the body of a begin block when it is converted to a
function.  

The assumption that every block ends with an executable statement turned out to
be false for modules.  But the conversion in callDestructors is only intended
to deal with blocks inside of functions, so I just filtered out that
troublesome case (module blocks) at the top of the loop.  


  DETAILS

    compiler/include/symbol.h
    compiler/AST/symbol.cpp
Added a new utility FnSymbol::insertBeforeDownEndCount(Expr*).

    compiler/passes/createTaskFunctions.cpp
Flatten the body of a begin block when it is turned into a function.

    compiler/passes/parallel.cpp
Use insertBeforeDownEndCount() instead of insertBeforeReturnAfterLabel() to
place the inserted autoDestroy calls ahead of that _downEndCount() call.

    compiler/resolution/callDestructors.cpp
In insertAutoDestroyCalls(), filter out blocks that are the children of a
module.  Add calls to "_downEndCount" to the list of special cases that can
terminate a block ahead of its last statement.

    test/users/ferguson/refcnt.execopts
Removed.  This was an earlier but ineffective attempt to resolve the
nondeterminism.


[tested on refcnt.chpl with both standard and --no-local]
[tested on domains/ distributions/ multilocale/ performance/ with comm=gasnet]
[testing on test/ using <std> (in progress)]


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22461 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding a future on a bug I found where external C functions specified as foo()
are not recognized by the compiler.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22462 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Beefing up a test, enabled by r22438, in test/parallel/taskPar/taskIntents.

When the test was created, I had to work around a bug (see
  test/parallel/begin/vass/begin-dom-arr-mem-corrupt.chpl
and its .future as of r22166). I did that using .patch files in src/.

Now that the bug is solved, the workaround is no longer necessary,
so I am deleting the .patch files and updating .chpl files,
which result from running 'make clobber all' in src/.

The support for .patch files in src/Makefile is now not needed,
but I am not bothering to remove it.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22463 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Categorized users/ferguson/no_args_varfunc.future to follow our conventions.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22464 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding a spec TODO about default values and inout / out arguments



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22465 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Prevent historify-logs from failing if mbp-kbrady isn't connected to the network

Add a '<command> || true' to prevent the script from failing if rsync cannot
reach mbp-kbrady.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22466 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Skip the distributions/vass/dmap-var-decl.chpl future on Mac.

It does not fail there, so turn it off to avoid testing noise.

While there, I added some spaces for beauty.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22467 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Another tweak on historify-logs.

[reviewed by Kyle]

A follow up to r22445 and r22466: if 'rsync' fails, print a reassuring
message that historification continues.

I chose not to count rsync failure as an "error" and keep script summary
positive if there were no other errors, mostly as a matter of taste.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22468 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing this future a little, as Brad pointed out that with a few tweaks and
throwing --no-cc-warnings the test will pass.  It is now a feature request
instead of a bug, as I believe the behavior is still not ideal.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22469 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
An update for TRIAGE/REGRESSIONS for this week.

* The refcnt test should now succeed, I removed its entry.

* Massive reduction in core dumps for linux64.pgi.none.fifo.pthreads.flat
on chpbld02, after six weeks of no testing logs:

11/04: total errors: 58;  "signal 11" crahses: 61
12/15: total errors: 15;  "signal 11" crahses: 12

I did not document this because I did not see how.

* weirdcase.chpl stopped timing out on gasnet-everything
I did not document this because I did not see how.

* A couple of nondeterministic segfaults under gasnet.qthreads
- recorded in TRIAGE

* hello3-datapar stopped timing out on gasnet-qthreads.
I updated REGRESSIONS.

* parallel/begin/vass/begin-dom-arr-mem-corrupt should no longer be
a passing future, starting 12/20.

* I removed the entry for simple-alias-mem-use failure from TRIAGE.
I do not see a reason to suspect that it failed recently - there are
no log files for these gnu/pgi/intel configurations on chpbld02
between 11/5 and 12/14.

* Removed from REGRESSIONS "CCE INTERNAL error" due to a CCE bug -
they were gone on 12/20 on chpbld01 for:
   cray-xc.cray-prgenv-cray.none.fifo.pthreads.flat--linux64.gnu
Still leaving an entry in TRIAGE - watch for
  Nightly/weekend/day6-Sat-cray-xe.cray-prgenv-cray.none.fifo.pthreads.flat--linux64.gnu-std.log

* Removed from TRIAGE the entry for refcnt - Tom fixed as of 12/20.

* Five random baseline compilation timeouts - in TRIAGE.

* spec/Classes/defineMethod regression has been fixed - removed from
REGRESSIONS.

* Recorded in REGRESSIONS three gasnet tests that fail with increased
comm counts, believed due to r22438. There is an email discussion
of what to do about those.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22470 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Upon further investigation from Brad, the emptyParamList test was only relevant
when CHPL_DEVELOPER was set, so it makes sense to remove it.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22471 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removed "proc ==(a: syserr, b: err_t)" and three other comparisons involving err_t in modules/standard/SysBasic.chpl.

[Reviewed/discussed with Brad and Michael.]

I am removing the following comparisons:

  inline proc ==(a: syserr, b: err_t)
  inline proc ==(a: err_t, b: syserr)
  inline proc !=(a: syserr, b: err_t)
  inline proc !=(a: err_t, b: syserr)

Explanation: Consider, for example, the first of the above.
SysBasic.chpl defined, since r21066:

  inline proc ==(a: syserr, b: err_t)
  inline proc ==(a: syserr, b: int(32))
  inline proc ==(a: syserr, b: int(64))

Since err_t is int(32), the first two functions always will be ambiguous
whenever one of them applies. I don't know why we have not hit this
ambiguity in our current code base, but it can get exposed.

Michael would like to make err_t distinct from int(32),
at which point this patch will need to be reverted.

Alternatively to removing, we could guard each function with
  where !_isIntegralType(err_t)
but that would make the current code less elegant.

Michael explains err_t:

  syserr is a pointer-based structure possiblycontaining an error code.
In order for it to be useful, one needs to be able to compare against
the system error codes like ENOENT or EINVAL. These should be wrapped in
the compiler as err_t values.

  I would rather solve the problem by having err_t be a different type
(with the same representation) that can compare against int(32); that
is, right now we have

 extern type err_t = c_int;

which makes err_t another name for c_int, but what I actually want is
for err_t to be a different type that has the same representation, and
to explicitly set which methods allow the combination of err_t and c_int
(as with == ).

  Of course, one way to do that would be to make err_t an opaque type...
but a more general way would be to support the generation of a new type
in these situations (e.g. new type err_t = c_int). 


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22472 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Cleaned up noRefCount-related code in modules/internal.

[reviewed by Tom]

Clarified the behavior that when noRefCount=true,
no reference counting or dist/domain/array deletion occurs.

This is based on code examination and common sense,
and discussed within the group.

* Added compilerAssert(!noRefCount) to incRefCount(), decRefCount(),
destroyDist(), destroyDom(), destroyArr(),
chpl_incRefCountsForDomainsInArrayEltTypes(),
chpl_decRefCountsForDomainsInArrayEltTypes().

* As a side effect, atomic operations on the reference counts are now
not performed at all when noRefCount=true. This should be beneficial
for performance in this mode when --no-local.

* Ensured that when noRefCount=true, the destructors for _distribution,
_domain, _array do nothing. Removed inner checks for !noRefCount.

While there...

* Moved the calls to remove_dom() and remove_array() from
destroyDist() and destroyDom(), for clarity.

* Wrapped those calls in 'local', to avoid 'on' clauses
when dealing with atomics in the callee.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22473 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Factor some routines out of build_constructor and build_type_constructor [reviewed by Lydia]

Factored segments of common code out of build_construtor and
build_type_constructor, and placed these in separate routines with mnemonic
names.

DETAILS

Added declarations for the new static functions: create_generic_arg,
insert_implicit_this and move_constructor_to_outer.
Applied a Boolean identity to simplify a logical expression.
Moved the common anti-recursion test and SET_LINENO call up into the caller:
build_constructors().
Added block comments.
Now, we wait until the function symbol is fully constructed before inserting it
into the class type.
Extracted generic argument creation code into create_generic_arg().
Extracted the code that converts local references to fields into fully-qualified
calls, and placed it in insert_implicit_this().
Extracted the common code for moving a constructor into an outer class into
move_constructor_to_outer().


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22474 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Simplify the implementation of homogeneous tuple operations

[reviewed by hilde]

Prior to this commit, we have been implementing all tuple operations (+, 
-, *, etc.) on singleton tuples, pairs of tuples, and tuple-scalar pairs 
using a recursive Lisp-y style of implementation approach.  While this 
approach is reasonably elegant to write and very general with respect to 
the tuple types, the code it generates is pretty ugly.  For example, a 
tuple addition like this:

   var x: 3*real = (1.0, 2.0, 3.0);
   var y: 3*real = (4.0, 5.0, 6.0);

   var z = x + y;

ends up looking like this:

   call_tmp = (1.0 + 4.0);
   ret_to_arg_ref_tmp_ = &wrap_call_tmp;
   chpl__tupleRestHelper2(1.0, 2.0, 3.0, ret_to_arg_ref_tmp_);
   ret_to_arg_ref_tmp_2 = &wrap_call_tmp2;
   chpl__tupleRestHelper2(4.0, 5.0, 6.0, ret_to_arg_ref_tmp_2);
   call_tmp2 = *(wrap_call_tmp + INT64(0));
   call_tmp3 = *(wrap_call_tmp2 + INT64(0));
   call_tmp4 = (call_tmp2 + call_tmp3);
   call_tmp5 = *(wrap_call_tmp + INT64(0));
   call_tmp6 = *(wrap_call_tmp + INT64(1));
   ret_to_arg_ref_tmp_3 = &wrap_call_tmp3;
   chpl__tupleRestHelper(call_tmp5, call_tmp6, ret_to_arg_ref_tmp_3);
   call_tmp7 = *(wrap_call_tmp2 + INT64(0));
   call_tmp8 = *(wrap_call_tmp2 + INT64(1));
   ret_to_arg_ref_tmp_4 = &wrap_call_tmp4;
   chpl__tupleRestHelper(call_tmp7, call_tmp8, ret_to_arg_ref_tmp_4);
   call_tmp9 = *(wrap_call_tmp3 + INT64(0));
   call_tmp10 = *(wrap_call_tmp4 + INT64(0));
   call_tmp11 = (call_tmp9 + call_tmp10);
   *(z + INT64(0)) = call_tmp;
   *(z + INT64(1)) = call_tmp4;
   *(z + INT64(2)) = call_tmp11;

In wrestling through generated code idioms like this for homogeneous 
tuples, I realized that there's no need to use the recursive approach 
because it's straightforward to anticipate the result type required, 
declare a variable for it, and fill the result using a param loop. This 
results in much cleaner generated code, like this:

   call_tmp = (1.0 + 4.0);
   call_tmp2 = (2.0 + 5.0);
   call_tmp3 = (3.0 + 6.0);
   *(z + INT64(0)) = call_tmp;
   *(z + INT64(1)) = call_tmp2;
   *(z + INT64(2)) = call_tmp3;

The primary challenge to doing the similar thing for heterogeneous tuples 
is that it's difficult to declare the result type using Chapel code today.
For homogeneous operations, we can say things like:

     var result: a.size*(a(1) + b(1)).type;

because we know that the type resulting from adding the 1st component will 
apply to all the others as well.  But for a heterogeneous case, we can't 
anticipate how many fields the tuple will have and don't have a way for 
mapping or expanding type-based computations like this across tuples (at 
least that I've been able to come up with so far).

So, in this commit, I provide specialized overloads of the operations for 
the (common) cases when the tuple(s) are homogeneous and preserve the 
original implementation for the fall-through case when one or both tuples 
are heterogeneous.

Another minor change in this commit is to mark the inner function in
chpl__tupleRest() inline to make the generated code in that case
somewhat simpler.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22475 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Slight simplification to yesterday's commit

[trivial, no review]

In adding some comments before committing as requested by Tom
yesterday, I realized that for unary operations, the result
type is easily inferred in both the homogeneous and heterogeneous
case, so collapsed these into a single, loop-based form rather
than the previous single, lisp-y style forme.   Added a test
to verify that types are preserved properly where the behavior
is unchanged since prior to this change.

(in writing up this test, am noting that we don't maintain
boolean widths in doing operations on booleans, as with other
types, which now seems inconsistent.  Will work on a future
for this behavior).




git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22476 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Future for preserving bool widths

It seems to me that we should preserve boolean widths when
operating on them, as with other small-int ops.  I'm guessing
this isn't hard, but am logging this to look into it later.



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