Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested foralls with zippering and a throwing function call results in internal compiler error #26912

Open
e-kayrakli opened this issue Mar 12, 2025 · 0 comments

Comments

@e-kayrakli
Copy link
Contributor

module nestedForallThrows {

  config const flag = true;

  proc main() throws {

    forall i in zip(1..10, 1..10) {

      var x = foo();

      forall j in 1..10 {
        writeln(i,j);
      }

    }
  }

  proc foo() throws {

    if flag {
      throw new Error();
    }


    return 0;
  }
}

Results in internal error: did not find the insertion point [resolution/lowerIterators.cpp:2154]. This issue is there on main and also on Chapel 2.3.

Looking deeper, I see that we place iterator break blocks based on _freeIterator calls. I see in the AST that we don't even have a _freeIterator for the follower of the outer forall. That's why we can't find a place to insert the iterator break block.

Some more notes:

  • change either loop to for and it works
  • make the outer loop non-zip and it works
  • it doesn't matter if the inner loop is zippered or not.
github-merge-queue bot pushed a commit to Bears-R-Us/arkouda that referenced this issue Mar 17, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
This PR is to assist #4176.

That PR makes `toSymEntry` a throwing function. Unfortunately, in the
histogram code, there are some nested foralls which are subject to [an
existing bug in the Chapel
compiler](chapel-lang/chapel#26912) that gets
exposed by making `toSymEntry` a throwing function. This PR adjusts the
histogram code to avoid that bug.

In general, the change here shouldn't be seen as a workaround, although
the implementation could still be less than ideal. When you have nested
`forall`s, in almost all cases, the outer one will grab all the cores in
the system, forcing the inner one to be sequential one. Where this PR
makes changes, it feels way more important for the inner loop to execute
in parallel compared to the outer one. Therefore, I expect the change
here to be an improvement for performance as well.

Signed-off-by: Engin Kayraklioglu <e-kayrakli@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant