@intFromFloat does not panic when expected for too-large floats

[mdiluz]

Zig Version

0.15.0-dev.695+041eedc1c

Steps to Reproduce and Observed Behavior

Use @intFromFloat to convert a floating point number to a small result type. Observe that safety checking does not occur in expected circumstances.

Test code:

const std = @import("std");
test "scalar" {
    // If this is const, the compiler figures out it can't fit into all of the below types
    var f: f32 = undefined;
    f = 1000;

    // Doesn't fit, but succeeds
    const u_9: u9 = @as(u9, @intFromFloat(f));
    std.debug.print("\n{d}", .{u_9});

    // Doesn't fit, but succeeds
    const i_10: i10 = @as(i10, @intFromFloat(f));
    std.debug.print("\n{d}\n", .{i_10});

    // Doesn't fit, invokes "integer part of floating point value out of bounds"
    // const i_4: i8 = @as(i8, @intFromFloat(f));
    // std.debug.print("\n{d}", .{i_4});
}

Output:

[2025-06-12T22:31:30.783Z] Running test: test.zig - scalar
1/1 test.test.scalar...
488
-24
OK
All 1 tests passed.

Expected Behavior

Based on the docs that say:

If the integer part of the floating point number cannot fit in the destination type, it invokes safety-checked Illegal Behavior.

I would expect an integer part of floating point value out of bounds panic from all of the @intFromFloat calls above, not just for i8.

[fardragon]

Looking at a reduced example on a74119ac49:

const std = @import("std");

pub fn main() !void {
    // If this is const, the compiler figures out it can't fit into all of the below types
    var f: f32 = undefined;
    f = 1000;

    // Doesn't fit, but succeeds
    const u_9: u9 = @as(u9, @intFromFloat(f));
    std.debug.print("\n{d}", .{u_9});
}

I see different behaviour with and without llvm, but both are wrong.:

❯ ../build/stage4/bin/zig run -fllvm main.zig

488

❯ ../build/stage4/bin/zig run main.zig             

1000

It feels like there is a truncate missing somewhere. Both for self hosted and llvm backend this https://github.com/ziglang/zig/blob/master/src/Sema.zig#L22205 subtraction seems to be doing 1000-1000 instead of 1000-488, which of course means the check passes.

Assembly debug

Self hosted:

LLVM:

The i8 version, which fails, seems to do the correct thing:

As does an u8 version:

In fact comparing the u9 and u8 versions on compiler explorer shows that's its doing something slightly different (probably something to do with 8 being a power of 2).

https://godbolt.org/z/6x69xxv37

Left: u9 Right: u8

As far as I understand the movsx eax, al in the u8 version truncates the value down to 8 bits, which makes the subsequent safety check work correctly, but the movzx eax, ax in the u9 version moves the entire 16bits of the 1000 that's in the ax register at that point, making the safety check do effectively nothing. Not sure if the correct approach to fixing this would be adding an explicit truncation in zirIntFromFloat or something else though, since the result type here https://github.com/ziglang/zig/blob/master/src/Sema.zig#L22202 being set explicitly makes me think that it might be incorrect lowering.

[bangbangsheshotmedown]

sorry for the noise, but that'll save future people's time, @fardragon i think it's better if you use permanent links that point to the source

[jacobly0]

The @intFromFloat(f) is illegal behavior but then the result is used to implement the safety check causing the safety check to also be illegal behavior. 😬

[mdiluz]

Thanks a ton @mlugg and @jacobly0 👍