Identical alts/bad divInt# code

This may be the same as #7360 (closed), but it may also be a problem in the code generation for divInt#. I've reduced it to the following minimal test case:

When compiling

fun :: Int -> Int
fun i = i `div` 2

with ghc -O2 -funfolding-use-threshold=150, the generated core becomes

Div2.fun =
  \ (i_aeH :: GHC.Types.Int) ->
    case i_aeH of _ { GHC.Types.I# ww_aiV ->
    case GHC.Prim.># ww_aiV 0 of _ {
      GHC.Types.False ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        };
      GHC.Types.True ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        }
    }
    }

with two identical case alternatives, and in the True case, the next comparison is guaranteed to return False.

The generated core is good if the divisor is negative, though, so that speaks for taking a look at divInt#.

Trac metadata

Trac field	Value
Version	7.6.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related	#7360 (closed)
Blocking
CC
Operating system
Architecture