For the first time I am writing a recursive parallel code in Chapel and it seems to send the compiler (both 2.7 and 2.8) into an endless loop repeatedly printing out the 1 statement:
“stoneNetr.chpl:172: called as construct(ys: [domain(1,int(64),one)] int(64), zs: [domain(1,int(64),one)] int(64)) from function 'construct'“
The code is already fairly long, so before I try to cut it down to post I was wondering whether Chapel actually supported recursive codes where the child function calls are inside cobegin statements?
I'm not aware of any reason that a recursive call within a cobegin isn't intended to work in Chapel (and even if it were intended, the compiler still shouldn't go into an infinite loop ).
Rather than cutting the code down to a smaller size, I wonder whether you'd be able to replicate the pattern of recursive parallelism in a new test to see if you got the same behavior?
You're welcome to share your full code if you're comfortable doing so (which is to say, while small reproducers are nice, a long code wouldn't necessarily make it harder for us to debug). Or, if you're uncomfortable sharing your full code, iI'd be curious to see key excerpts, like:
the definition and call to the construct() procedure that the error above is referring to
the approximate structure of the cobegin it's taking place within
The part of the error message before the endlessly repeated line you gave above would be interesting as well.
In the process of trying to create a minimal code I ended up finding a bunch of other bugs in my code. Fixing those made the compiler happy again! The downside is that I lost the original code that caused the infinite loop in the compiler!
OK, glad that you've got traction again, but sorry to hear that we lost
the infinite code. Needless to say, if you come back across it again,
we'd be interested in examining that.