Skip to content

usize/isize vector comparison within function #4334

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

Closed
travisstaloch opened this issue Jan 30, 2020 · 6 comments
Closed

usize/isize vector comparison within function #4334

travisstaloch opened this issue Jan 30, 2020 · 6 comments
Labels
bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend.
Milestone

Comments

@travisstaloch
Copy link
Contributor

on 30 Jan 2020 with zig version 0.5.0+7ebc624a1 pulled and built from master last night.

In the following code, two @Vector(4, usize) are compared with == in the test scope with no problem. However if the same comparison is made within a struct fn, the == comparison results in:

error: expected type '@Vector(4, u64)', found '@Vector(4, usize)'

It appears that the lhs @Vector(4, usize) is being converted to @Vector(4, u64) when it gets passed into a function. This error is not observed with u64 vector type.

//
// $ zig test repro.zig
// ./repro.zig:15:29: error: expected type '@Vector(4, u64)', found '@Vector(4, usize)'
//             const eqs = self.limbs == other.limbs; // <--- here
//                             ^
// ./repro.zig:15:36: note: referenced here
//             const eqs = self.limbs == other.limbs; // <--- here
//                                    ^
//

test "repro: vector == with usize/isize" {
    const S = struct {
        limbs: @Vector(4, usize), // this error also occurs with isize
        pub fn equals(self: @This(), other: @This()) bool {
            // error: expected type '@Vector(1, u64)', found '@Vector(1, usize)'
            const eqs = self.limbs == other.limbs; // <--- here
            return true;
        }
    };
    const s1 = S{ .limbs = @splat(4, @as(usize, 0)) };
    const s2 = S{ .limbs = @splat(4, @as(usize, 0)) };
    const eqs = s1.limbs == s2.limbs; // here == with usize vectors is ok
    const eq = s1.equals(s2);
}
@FireFox317
Copy link
Contributor

Maybe it has something to do with the fact that @This() is called twice? A pattern that is common is put a definition in the struct: const Self = @This() and use Self instead.

@LemonBoy
Copy link
Contributor

The code that lowers the comparison between two vectors uses @Vector(4, u64) as type for the intermediate computations since it's compatible (size-wise and signedness-wise) with both the LHS and the RHS. Too bad that you cannot (yet?) coerce a @Vector(4, usize) to a @Vector(4, u64) even though usize is equal to u64. The error message reflects this implementation detail.

@travisstaloch
Copy link
Contributor Author

@FireFox317 I tried with const Self = @This() but removed it trying to make minimal repro.
@LemonBoy any ideas where to start on making the coercion happen? I might attempt myself.

@LemonBoy
Copy link
Contributor

any ideas where to start on making the coercion happen? I might attempt myself.

You should check first with @andrewrk if that's supposed to work. Check out ir_analyze_bin_op_cmp_numeric to see where this happens and how dest_scalar_type is evaluated.

@travisstaloch
Copy link
Contributor Author

Too bad that you cannot (yet?) coerce a @vector(4, usize) to a @vector(4, u64) even though usize is equal to u64

@andrewrk should this coerce?

Related to: #903 and #3641

@andrewrk
Copy link
Member

Yes that should coerce. As long as each of the element values coerce and the length matches then the whole vector should.

A workaround is @bitCast.

@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend. labels Feb 10, 2020
@andrewrk andrewrk added this to the 0.7.0 milestone Feb 10, 2020
LemonBoy added a commit to LemonBoy/zig that referenced this issue Feb 12, 2020
Only valid when the number of elements match and the types are
compatible.

Fixes ziglang#4334
@andrewrk andrewrk modified the milestones: 0.7.0, 0.6.0 Feb 29, 2020
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 stage1 The process of building from source via WebAssembly and the C backend.
Projects
None yet
Development

No branches or pull requests

4 participants