miri: fix ICE when running out of address space

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup

[RalfJung]

Fixesrust-lang/miri#2769
r? @oli-obk

I didn't add a test since that requires oli-obk/ui_test#38 (host must be 64bit and target 32bit). Also the test takes ~30s, so I am not sure if we want to have it in the test suite?

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Ah, the Vec-based version of the test is actually instantaneous:

//@only-32bit//@only-host-x86_64fnmain(){for _ in0..4{letmut a:Vec<u8> = Vec::with_capacity(1024*1024*1024);let _ptr = a.spare_capacity_mut().as_ptr();}}

Still blocked on oli-obk/ui_test#38 though.

[oli-obk]

🤣 the following rustc program takes 40s to compile on my machine, and uses around 10GB of RAM on a "32 bit machine" (the const evaluator's emulated target):

constFOO:() = {foo(10);};constfnfoo(x:usize){if x != 0{letmut array = [0_u8; usize::MAX / 4];foo(x - 1);
array[array.len() - 1] = 42;}}fnmain(){FOO;}

obvious in hindsight, and could even be useful for embedded systems doing lotsa work at compile-time, but it makes absolutely no sense outside of the "all addresses are symbolic" scheme

[oli-obk]

@bors r+

[bors]

📌 Commit 2900ba1 has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah, in CTFE we can totally have more than 4GB of virtual address space with 32bit pointers. With perfect provenance tracking we can basically assign the same physical address multiple times and there is no possibility of confusion. (We don't actually assign any physical address of course, but we could imagine that we did.)

[oli-obk]

@bors rollup