diku-dk / futhark

:boom::computer::boom: A data-parallel functional programming language
http://futhark-lang.org
ISC License
2.4k stars 166 forks source link

Internal compiler error: combineAliases invalid args #2096

Closed nqpz closed 9 months ago

nqpz commented 9 months ago

The program

entry main (x: i32): (i32, bool) =
  let when pred action orig = if pred
                              then action orig
                              else orig

  let action = when true (\(x, _) -> (x, true))

  in if true
     then action (x, false)
     else action (x, false)

results in this error message when run with futhark c from git:

Internal compiler error (unhandled IO exception).
Please report this at https://github.com/diku-dk/futhark/issues
combineAliases invalid args: (Scalar (Record (fromList [(Name "0",Scalar (Prim (Signed Int32))),(Name "1",Scalar (Prim Bool))])),Scalar (TypeVar (fromList [AliasBound {aliasVar = VName (Name "action") 4504},AliasFree {aliasVar = VName (Name "internal_app_result") 1},AliasFree {aliasVar = VName (Name "internal_app_result") 2},AliasFree {aliasVar = VName (Name "internal_app_result") 3},AliasFree {aliasVar = VName (Name "action") 4494},AliasFree {aliasVar = VName (Name "orig") 4496}]) (QualName {qualQuals = [], qualLeaf = VName (Name "t\8322") 4497}) []))
CallStack (from HasCallStack):
  error, called at src/Language/Futhark/TypeChecker/Consumption.hs:407:3 in futhark-0.26.0-inplace:Language.Futhark.TypeChecker.Consumption
athas commented 9 months ago

An interesting but in retrospect obvious bug, and the most surprising thing is that we have not seen it before.

The issue arises when we have more specific aliasing information available than is truly needed; in this case because we combine specific aliasing information from a tuple with more generic aliasing information from a type variable. We can shrink the program to this:

entry main (x: i32): (i32, bool) =
  let localid x = x
  in if true
     then localid (x, false)
     else localid (x, false)
athas commented 9 months ago

Oh, actually we do handle that, but I just forgot to make the relationship symmetric...