Using `undef` in `match`-else branch triggers a `bottom` def

[PearCoding]

Using the undef[T]() method for complex types in match inside the else/otherwise code produces an error like the following:

Terminator found in the middle of a basic block!
label %match_otherwise
Operand is null
  %cont3 = phi i32 [ %3, %case_body ], [ %4, %case_body1 ], [ %5, %case_body2 ], [ <null operand!>, %match_otherwise ]

The issue can be reproduced with the following code test.zip. Without the main3_err function the code passes. Use artic test.art --emit-llvm to compile.

The issue was detected on Linux Ubuntu first.

Used libraries:

• thorin: master
• artic: master
• runtime: development

[Hugobros3]

I got a different error in my reproduction:

artic: /home/gob/git/anydsl/thorin/src/thorin/be/llvm/llvm.cpp:618: void thorin::llvm::CodeGen::emit_epilogue(thorin::Continuation*): Assertion `call_instr && "returning calls always involve one of those"' failed.`

A few questions/remarks:

• Why a zip file if you only have one file ?
• Please use exact commits!

• Is undef[] of a function type really a sane way to express unreachable ? Seems funky!

  I introduced a regression when calling undef when refactoring the LLVM backend, https://github.com/AnyDSL/thorin/commit/2400342888fe9e04111ed6c74003c7901717e221 should revert it. We should perhaps also add a test in Artic to ensure this behavior works.

[PearCoding]

• .art files are not allowed on Github... And it was easy to just zip it :D
• thorin 7793f10424502c9e3afe84cef99c3e3c12728764
• Yes, it is indeed a bad idea. But artic allows this, so someone (e.g., me) might do it. I still had the c/++ idea floating around that a function is a pointer.

We could use a adapted variant of the zip I send to test this in artic.

[PearCoding]

Oh, also I do get the same error when I have thorin with checks and debug. Forgot to mention that.

[PearCoding]

@Hugobros3 fixed it with https://github.com/AnyDSL/thorin/commit/2400342888fe9e04111ed6c74003c7901717e221