Hi Zhao/Michael/all --
For reference, I believe that this is a known issue. From
$CHPL_HOME/STATUS[.devel]:
- Modules that use another module that uses a begin statement in its
initialization result in an internal compiler error.
# test/parallel/begin/vass/begin-in-module-init.future
Another way to work around it is to wrap the code at file scope at the end
of the file into a main procedure as shown just below.
-Brad
proc main() {
use OurModule;
// At this point we have not used ChildModule or SiblingModule so their
symbols
// (i.e. foo ) are not available to us.
// However, the module names are, and we can explicitly call foo() through
them.
SiblingModule.foo(); // Calls SiblingModule.foo()
// Super explicit naming.
OurModule.ChildModule.foo(); // Calls ChildModule.foo()
use ChildModule;
foo(); // Less explicit call on ChildModule.foo()
sync {
begin { // Start of new task's body
var a = 0;
for i in 1..1000 do a += 1;
writeln( "Done: ", a);
} // End of new tasks body
writeln( "spun off a task!");
}
writeln( "Back together" );
}
On Thu, 17 Mar 2016, Michael Ferguson wrote:
Hi -
I've reproduced this bug on master.
It seems that the compiler-generated function containing the
default-module code, chpl__init_bug, has an extra argument
for _endCount. This argument is not present if these last
10 lines are removed.
Interestingly, if these last 10 lines are put in their
own file, it compiles.
So, I would guess that some part of the compiler is
erroneously adding the _endCount argument to this
module init function.
I'll add this to our test system as a bug report .future.
-michael
On 3/17/16, 6:01 AM, "赵亮" <[email protected]> wrote:
Chapel homebrew version:
chpl Version 1.12.0
Copyright (c) 2004-2015, Cray Inc. (See LICENSE file for more details)
printchplenv output:
machine info: Darwin zhaoliangdeMacBook-Pro.local 14.5.0 Darwin Kernel
Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015;
root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
CHPL_HOME: *
script location: /usr/local/Cellar/chapel/1.12.0/libexec/util
CHPL_HOST_PLATFORM: darwin
CHPL_HOST_COMPILER: clang
CHPL_TARGET_PLATFORM: darwin
CHPL_TARGET_COMPILER: clang
CHPL_TARGET_ARCH: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_MEM: cstdlib
CHPL_MAKE: make
CHPL_ATOMICS: intrinsics
CHPL_GMP: gmp
CHPL_HWLOC: hwloc
CHPL_REGEXP: re2
CHPL_WIDE_POINTERS: struct
CHPL_LLVM: none
CHPL_AUX_FILESYS: none
Chpl compiler output:
bug.chpl:315: internal error: EXP5639 chpl Version 1.12.0
Internal errors indicate a bug in the Chapel compiler ("It's us, not
you"),
and we're sorry for the hassle. We would appreciate your reporting this
bug --
please see http://chapel.cray.com/bugs.html for instructions. In the
meantime,
the filename + line number above may be useful in working around the
issue.
I was just trying to go through the chapel
tutor <https://learnxinyminutes.com/docs/chapel/> when I came across this
bug. So it's just trivial code.
It works fine if I remove the last 10 lines(the 'sync' statement starting
from line 354). It's kind of weird.
--zhao
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Chapel-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-bugs
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Chapel-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-bugs
