Mark comptime int hardcoded address pointee as a run time variable #1171

[justinbalexander]

This fixes the compiler error from #1171.

Without this line, it was set to ConstPtrMutComptimeVar.

[andrewrk]

Looks good. Can you add a new test to cover this? Something like:

const myP = @intToPtr(*u16, 0x2300);

test "mutate through ptr initialized with constant intToPtr value" {
  myP.* = myP.* | 10;
}

Probably a good place for it would be test/cases/inttoptr.zig.

[justinbalexander]

Would the only requirement for the test to pass be that there is no compile error? I don't think I can test the actual contents of a hardcoded address in user space?

…

On Fri, Jan 4, 2019, 1:39 PM Andrew Kelley ***@***.*** wrote: Looks good. Can you add a new test to cover this? Something like: const myP = @intToPtr(*u16, 0x2300); test "mutate through ptr initialized with constant intToPtr value" { myP.* = myP.* | 10; } Probably a good place for it would be test/cases/inttoptr.zig. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1868 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Alxeiwo5rPobU6qoBVawjhgNk6LRu-zcks5u_63bgaJpZM4Zrg3m> .

[andrewrk]

Oops, good point. What we can do is put the logic in an if statement that will always be false, but make the compiler unable to determine the value at compile-time, so that it must analyze the branch. One way to do this, for example, is to pass false as a bool parameter, and then do an if on that bool.

This may be another good candidate for LLVM IR tests, when I get around to introducing that kind of test.

[justinbalexander]

Like so?

test "mutate through ptr initialized with constant intToPtr value" {
    forceCompilerAnalyzeBranchHardCodedPtrDereference(false);
}

fn forceCompilerAnalyzeBranchHardCodedPtrDereference(x: bool) void {
    const hardCodedP = @intToPtr(*volatile u8, 0xdeadbeef);
    if (x) {
        hardCodedP.* = hardCodedP.* | 10;
    } else {
        return;
    }
}

It does pass.

[andrewrk]

Looks good to me.

[justinbalexander]

Can the compiler not see that we pass in a comptime known value as the parameter and omit the unused path?

…

On Fri, Jan 4, 2019, 3:30 PM Andrew Kelley ***@***.*** wrote: Looks good to me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1868 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Alxei8lVRQYAnNsrozPZ998fXXD44eeJks5u_8gMgaJpZM4Zrg3m> .

[andrewrk]

It used to do that implicitly, but not anymore. There are some problems to solve when trying to reinstate that behavior. The issue to track is #425. If we ever changed this behavior, a lot of tests would have to be modified, which rely on this behavior. So safe to assume that this new test case would be part of that audit.

[justinbalexander]

Do I need to re-trigger the build before acceptance?

[andrewrk]

It's building. Should be done in about an hour. But enough of the tests pass that I'm confident it will finish successfully, so I'll go ahead and merge. Thanks again for the fix!