Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sema: incorrectly simplifies comptime zero divided by runtime float #22749

Open
jacobly0 opened this issue Feb 4, 2025 · 0 comments · May be fixed by #22776
Open

Sema: incorrectly simplifies comptime zero divided by runtime float #22749

jacobly0 opened this issue Feb 4, 2025 · 0 comments · May be fixed by #22776
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Milestone

Comments

@jacobly0
Copy link
Member

jacobly0 commented Feb 4, 2025

const std = @import("std");
const nan = std.math.nan;
var rt_nan: @Vector(1, f32) = .{nan(f32)};
var rt_zero: @Vector(1, f32) = .{0};
const ct_zero: @Vector(1, f32) = .{0};
pub fn main() void {
    std.debug.print("{} {}\n", .{ @divTrunc(rt_zero, rt_nan), @divTrunc(ct_zero, rt_nan) });
    std.debug.print("{} {}\n", .{ @divFloor(rt_zero, rt_nan), @divFloor(ct_zero, rt_nan) });
}
$ zig run repro.zig
{ nan } { 0e0 }
{ nan } { 0e0 }

As an added bonus for fixing this bug, you can delete the lines in test/behavior/x86_64/math.zig referencing this issue!

@jacobly0 jacobly0 added bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness. labels Feb 4, 2025
@jacobly0 jacobly0 added this to the 0.15.0 milestone Feb 4, 2025
tau-dev added a commit to tau-dev/zig that referenced this issue Feb 5, 2025
Close ziglang#22749, close ziglang#22748, complete the "if the RHS is one, return the
LHS directly" TODOs, fix a crash on `intvec{undefined} / intvec{-1}` and
fix some compile errors:

* @divExact should not cause a compile error for integer undefined lhs
  and runtime-known rhs, because execution is completely legal when
  rhs == 1, and the policy on other operations has so far been to only
  error if illegal behavior is guaranteed to happen.
* Compile errors for float division by zero make little sense given that
  they are perfectly well-defined IEEE operations. The comments suggest
  that this was possibly made illegal intentionally, maybe in service of
  explicitness / "only way to do things" (so you have to use math.inf /
  math.nan), but that would contradict the general principle that
  comptime operations behave like runtime, and would add annoying
  special-cases to some comptime calculations.
  The @...Div() intrins allowed only *floating-point zero divided by
  zero*, which should be, if anything, *more* ill-defined any other
  division by zero, and probably shouldn't result in zero.
@tau-dev tau-dev linked a pull request Feb 5, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant