internal error: UTI-MIS-0928 chpl version 1.26.0 pre-release (b3897ad689)

jlbyrne-hpe commented 2 years ago

Summary of Problem

Both the pre-release and 1.25 compilers get internal errors with the code below. (The error for 1.25.0 ends in -0921)

I don't know if I'm blocked, yet, When I was working to reduce it to a minimal test case, I saw some sensitivity that suggested possible workarounds.

Steps to Reproduce

Source Code: spam.chpl

module Spam {
    use BlockDist;
    use CPtr;

    type region_desc = c_ptr(void);

    class sam {
        proc lookup_region(regionName:string): region_desc throws {
            return c_nil;
        }
    }

    var sammy = new sam();

    private proc regionLookups(ref regionDescs, regionName: string) throws {
        // Won't break if the try isn't there.
        try {
            // The "with in" seems to be required as well
            forall r in regionDescs with (in regionName) {
                r = sammy.lookup_region(regionName);
            }
        }
    }

    private proc lookup(regionName: string) throws {
        var regionDescs = newBlockArr(0..#numLocales, region_desc);
        regionLookups(regionDescs, regionName);
    }

    proc main() : int {
        try! lookup("a");

        return 0;
    }
}

Compile command: chpl -o ~/spam ~/spam.chpl

Execution command:

Associated Future Test(s): test/parallel/forall/in-intents/bug-18742-potentially-error-handling-related.chpl test/parallel/forall/in-intents/bug-18742-potentially-error-handling-related2.chpl #26224

Configuration Information

Output of chpl --version: chpl version 1.26.0 pre-release (b3897ad689) built with LLVM version 11.0.1
Output of $CHPL_HOME/util/printchplenv --anonymize: CHPL_TARGET_PLATFORM: linux64 CHPL_TARGET_COMPILER: clang CHPL_TARGET_ARCH: x86_64 CHPL_TARGET_CPU: native CHPL_LOCALE_MODEL: flat CHPL_COMM: none CHPL_TASKS: qthreads CHPL_LAUNCHER: none CHPL_TIMERS: generic CHPL_UNWIND: none CHPL_MEM: jemalloc CHPL_ATOMICS: cstdlib CHPL_GMP: bundled CHPL_HWLOC: bundled CHPL_RE2: bundled CHPL_LLVM: bundled * CHPL_AUX_FILESYS: none
Back-end compiler and version, e.g. gcc --version or clang --version: clang version 11.0.1 (git@github.com:chapel-lang/chapel.git b3897ad6899d6758574658bc5573d3ef16e3d24d) Target: x86_64-unknown-linux-gnu Thread model: posix

bradcray commented 2 years ago

Hi John —

This is a quick note to let you know that I've reproduced it, and that the failing behavior is somewhat similar to two other completely separate issues that I've been looking into this week. I'm not sure whether there's a common root cause for all three cases or not. I also haven't gotten far enough to be able to figure out what the root cause is in your case or whether there's an obvious workaround. I need to switch to some time-sensitive SC21 deliverables now, but hope to spend some more time on this this week (if nobody else does before I do).

bradcray commented 2 years ago

On a whim tonight, I tried compiling this to see whether things had gotten any better and found:

I updated CPtr to CTypes to reflect recent module reorganizations
as written, and using the LLVM back-end, it errors with the following, which seems strictly better than the internal error it was getting: error: Could not find C type for void
changing c_ptr(void) to c_void_ptr (which is something we've discussed doing automatically, but haven't discussed enough to agree upon yet) OR compiling with the C back-end with the original code, I get internal error: COD-CG--XPR-1579, which is also strictly better than the original internal error. The developer view of that error is internal error: misuse of codegenAddrOf [codegen/cg-expr.cpp:1579]

All of this is with chpl version 1.28.0 pre-release (11d7b28e92).

vasslitvinov commented 11 months ago

As of a couple of days ago, Chapel a55eabba7f, the original error is still there. With --verify, it fails during verification after lowerIterators with a SymExpr for a symbol "not in the tree."

trivially updated code from the OP

```chpl module Spam { use BlockDist; use CTypes; type region_desc = c_ptr(void); class sam { proc lookup_region(regionName:string): region_desc throws { return nil; } } var sammy = new sam(); private proc regionLookups(ref regionDescs, regionName: string) throws { // Won't break if the try isn't there. try { // The "with in" seems to be required as well forall r in regionDescs with (in regionName) { r = sammy.lookup_region(regionName); } } } private proc lookup(regionName: string) throws { var regionDescs = blockDist.createArray(0..#numLocales, region_desc); regionLookups(regionDescs, regionName); } proc main() : int { try! lookup("a"); return 0; } } ```

lydia-duncan commented 1 week ago

Thanks for saving the updated version of the code, Vass, and pointing out the --verify behavior. I'm adding it as a future in #26224, it does look like the failure is still present (and it seems like --verify is the way to get it to be consistent)

chapel-lang / chapel