An in-place wrapper around a pure function can introduce a memory aliasing bug

[passionsocks]

This snippet of code demonstrates the bug, as observed in Zig 0.7.1

// unexpected_aliasing.zig
const std = @import("std");

// pure complex multiplication -- returns a * b
fn complexPureMult(a: [2]f32, b: [2]f32) [2]f32 {
    return [2]f32{
        a[0] * b[0] - a[1] * b[1],
        a[0] * b[1] + a[1] * b[0],
    };
}

// inplace complex multiplication -- a *= b;
fn complexInplaceMult(a: *[2]f32, b: [2]f32) void {
    a.* = complexPureMult(a.*, b);
}

test "inplace_product_result_alias_bug_in_debug" {
    const identity = [2]f32{ 1, 0 };
    const nonidentity = [2]f32{ 4, 5 };

    const pure_result = complexPureMult(identity, nonidentity);
    std.testing.expectEqual(nonidentity[0], pure_result[0]);
    std.testing.expectEqual(nonidentity[1], pure_result[1]);

    var inplace_result = identity;
    complexInplaceMult(&inplace_result, nonidentity);
    std.testing.expectEqual(nonidentity[0], inplace_result[0]);
    std.testing.expectEqual(nonidentity[1], inplace_result[1]); // "expected 5.0e+00, found 2.0e+01"
}

Running the test in the default (-O Debug) build mode gives the indicated error with the inplace result on my x86_64-linux desktop machine.

$ zig version
0.7.1
$ zig test unexpected_aliasing.zip
Test [1/1] test "inplace_product_result_alias_bug"... expected 5.0e+00, found 2.0e+01
[...]

The generated code for complexPureMult shows that it does not expect the destination for the result to be an alias for the first argument, as it computes the first term (reading memory for all four values) and writes it to the destination before computing the second term (rereading all four values).

However complexInplaceMult violates the assumption, so the computed value is incorrect.

[travisstaloch]

#4021 maybe.

[daurnimator]

Closing as dupe of #3696