correctness_lossless_cast fuzz failure

[alexreinking]

Discovered in CI on #9001:

constant_integer_bounds failure
seed = 1617303089
x = 3
buf_u8 = 238
buf_i8 = -22
out1 = 5207780
Expression: int64(int32(let t3490 = (uint8)buf_u8(x) in int16((int8)78/int8((t3490/(uint8)194) - uint8(int16(t3490/(uint8)194))))) - (int32((uint16)194*uint16((int8)buf_i8(x)))*int32((((uint8)buf_u8(x)/(uint8)194) - uint8(int16((uint8)buf_u8(x)/(uint8)194))) + uint8((int8)-85*int8(int16((uint8)buf_u8(x)/(uint8)194))))))
Bounds: [-16711503, 78]
Simplified: int64(0 - (int32(uint16((int8)buf_i8(x))*(uint16)194)*int32(uint8(int8((uint8)buf_u8(x)/(uint8)194)*(int8)-85))))
Bounds: [-16711425, 0]
lossless_cast fuzz test failed!

[alexreinking]

Claude Opus 4.6 wasted almost an entire context window struggling to figure out how to recreate an Expr from the pretty-printed Expr. It failed outright. To my shame, it look me a solid 3-4 minutes of fiddling to get it to compile. Here's the expression in C++:

    Expr t3490 = Variable::make(UInt(8), "t3490");
    Expr e = cast<int64_t>(
        cast<int32_t>(
            Let::make(
                "t3490",
                cast<uint8_t>(buf_u8(x)),
                cast<int16_t>(cast<int8_t>(78) / cast<int8_t>(t3490 / cast<uint8_t>(194) - cast<uint8_t>(cast<int16_t>(t3490 / cast<uint8_t>(194))))))) -
        cast<int32_t>(
            cast<uint16_t>(194) * cast<uint16_t>(cast<int8_t>(buf_i8(x)))) *
            cast<int32_t>(
                cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194) - cast<uint8_t>(cast<int16_t>(cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194))) +
                cast<uint8_t>(
                    cast<int8_t>(-85) * cast<int8_t>(cast<int16_t>(cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194))))));

Also, for some reason, that seed isn't portable from arm-32-linux to arm-64-osx. Either it's the previous one or something is fishy with this test's randomness management.

We need some way of printing Exprs in a C++-compatible syntax for quick debugging. Serialization is one thing. This is another. Maybe @mcourteaux wants to take a stab at this?

[alexreinking]

This is clearly an issue with the arm-32 backend:

void test_regression() {
    Expr t3490 = Variable::make(UInt(8), "t3490");
    Expr e = cast<int64_t>(
        cast<int32_t>(
            Let::make(
                "t3490",
                cast<uint8_t>(buf_u8(x)),
                cast<int16_t>(cast<int8_t>(78) / cast<int8_t>(t3490 / cast<uint8_t>(194) - cast<uint8_t>(cast<int16_t>(t3490 / cast<uint8_t>(194))))))) -
        cast<int32_t>(
            cast<uint16_t>(194) * cast<uint16_t>(cast<int8_t>(buf_i8(x)))) *
            cast<int32_t>(
                cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194) - cast<uint8_t>(cast<int16_t>(cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194))) +
                cast<uint8_t>(
                    cast<int8_t>(-85) * cast<int8_t>(cast<int16_t>(cast<uint8_t>(buf_u8(x)) / cast<uint8_t>(194))))));

    Expr simplified = simplify(e);
    std::cout << "Original: " << e << "\n";
    std::cout << "Simplified: " << simplified << "\n";

    ConstantInterval orig_bounds = constant_integer_bounds(e);
    ConstantInterval simp_bounds = constant_integer_bounds(simplified);
    std::cout << "Original bounds: " << orig_bounds << "\n";
    std::cout << "Simplified bounds: " << simp_bounds << "\n";

    buf_u8.fill(238);
    buf_i8.fill(-22);

    Func f{"f"};
    f(x) = e;

    Func simple{"simple"};
    simple(x) = simplified;

    Buffer<int64_t> out_f(1, "out_f");
    f.realize({out_f});

    Buffer<int64_t> out_simple(1, "out_simple");
    simple.realize({out_simple});

    std::cout << "out_f = " << out_f(0) << "\n";  // prints -10476828
    std::cout << "out_simple = " << out_simple(0) << "\n";  // prints -10476828
}

I ran this in place of main in correctness_lossless_cast.cpp. On my arm64 Mac, it returned the same, in-bounds value.

[alexreinking]

Restarting with this test in place, Claude figured out what's going on:

  I can prove the value 5,207,780 comes from a sign-extension error:

  With buf_u8(3) = 238, buf_i8(3) = -22:

  Factor B (the uint16 product cast to int32):
  - uint16(int8(-22)) = 65514
  - 65514 * 194 mod 65536 = 61268
  - int32(61268) = 61268

  Factor C (the uint8 sum cast to int32):
  - uint8(238) / uint8(194) = 1
  - subtraction part: 1 - uint8(int16(1)) = 0
  - addition part: uint8(int8(-85) * int8(1)) = uint8(-85) = 171
  - total: 0 + 171 = 171 (uint8)
  - int32(171) should be 171 (zero-extend)

  Correct result: 0 - (61268 * 171) = 0 - 10,476,828 = -10,476,828

  But if the uint8(171) is sign-extended as int8(-85):
  - int32(-85) = -85
  - 61268 * (-85) = -5,207,780
  - 0 - (-5,207,780) = 5,207,780

[alexreinking]

Another similar bug surfaced while testing #9017

seed = 1285379505
x = 3
buf_u8 = 251
buf_i8 = -5
out1 = 236
Expression: int64(widening_add(~((int16(~((uint8)216))/(int16)216)*int16((int8)-13 + (int8)5))/(int16(~((uint8)216))/(int16)216), int16((uint8)rounding_shift_right((uint8)216, (uint8)buf_u8(x)/(uint8)216))))
Bounds: [108, 218]
Simplified: int64(widening_add((int16)0, int16((uint8)rounding_shift_right((uint8)216, (uint8)buf_u8(x)/(uint8)216))))
Bounds: [108, 217]
lossless_cast fuzz test failed!

https://buildbot.halide-lang.org/master/#/builders/395/builds/231