Skip to content

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jul 10, 2024

The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.

The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.

r? @saethlin

try-job: i686-msvc
try-job: test-various

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 10, 2024
@workingjubilee workingjubilee marked this pull request as ready for review July 10, 2024 03:16
|
LL | static MY_TOO_BIG_ARRAY_2: [u8; HUGE_SIZE] = [0x00; HUGE_SIZE];
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ values of the type `[u8; 2305843009213693951]` are too big for the current architecture
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ values of the type `[u8; 2305843009213693952]` are too big for the current architecture
Copy link
Member Author

@workingjubilee workingjubilee Jul 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it was literally 1 byte too small to be oversized (at least, according to the relevant check).

@rust-log-analyzer

This comment has been minimized.

@workingjubilee
Copy link
Member Author

I don't know how to fix the gcc errors?

@workingjubilee
Copy link
Member Author

wait these are the 32-bit errors... good, actually, I was wondering.

The comment here about 48 bit addresses being enough was written in 2016
but was made incorrect in 2019 by 5-level paging, and then persisted for
another 5 years before being noticed and corrected.
These tests depend on the internal logic of rustc regarding handling
very large objects. Fix them to reflect rustc_abi::obj_size_bound diffs.
@workingjubilee workingjubilee force-pushed the 5-level-paging-exists branch 2 times, most recently from 98c3e20 to f04e444 Compare September 19, 2024 23:47
@saethlin saethlin self-assigned this Sep 19, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment was marked as outdated.

@workingjubilee
Copy link
Member Author

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 20, 2024
…, r=<try>

Correct outdated object size limit

The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.

The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.

try-job: i686-msvc
try-job: test-various
@bors
Copy link
Collaborator

bors commented Sep 20, 2024

⌛ Trying commit 8431855 with merge cfa946e...

@bors
Copy link
Collaborator

bors commented Sep 20, 2024

☀️ Try build successful - checks-actions
Build commit: cfa946e (cfa946ee32abd52e574ce20c91b3890facc7a8f7)

@saethlin
Copy link
Member

Having read the error text here a zillion times, I now want it to say something like "are too big for the target architecture (x86_64)" because "current" could mean the host. If you agree, you can do that here. Otherwise, r=me.

@workingjubilee
Copy link
Member Author

It is done. Adding the architecture as a param is a cool idea, but requires unifying the source of this error message. There are at least 4 separate instances of it, and the moment I attempted such a unification, a herd of yaks appeared, so I will not be doing that.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Sep 20, 2024

The Miri subtree was changed

cc @rust-lang/miri

@workingjubilee
Copy link
Member Author

@rustbot ready

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 20, 2024
@saethlin
Copy link
Member

@bors r+ rollup=iffy

@workingjubilee
Copy link
Member Author

@bors r=saethlin

@bors
Copy link
Collaborator

bors commented Sep 20, 2024

📌 Commit d93d2f1 has been approved by saethlin

It is now in the queue for this repository.

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 21, 2024
…, r=saethlin

Correct outdated object size limit

The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.

The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.

try-job: i686-msvc
try-job: test-various
@bors
Copy link
Collaborator

bors commented Sep 21, 2024

⌛ Testing commit d93d2f1 with merge 9bbc9f4...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Sep 21, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 21, 2024
@@ -337,23 +337,21 @@ impl TargetDataLayout {
Ok(dl)
}

/// Returns exclusive upper bound on object size.
/// Returns **exclusive** upper bound on object size.
///
/// The theoretical maximum object size is defined as the maximum positive `isize` value.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not entirely sure what is even meant by "object". In general we are saying that "allocated objects" are limited by isize::MAX, and we do not publicly document anything else even for 64bit targets. So we do currently allow people to create heap allocations larger than obj_size_bound, and we rely on LLVM supporting that. It is only Rust types that can't be any bigger, and therefore static and let-bound variables and Box.

So either we should clarify the comment to say that this does not apply to all heap allocations, or we need to fix our docs.

@nikic will LLVM miscompile things if a heap allocation gets bigger than 2^61 bytes because that overflows u64 when counting in bits? Or does the 2^64 bits limit only apply to LLVM "typed objects"? Or is this too theoretical because nothing can be that big anyway? ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would only be a problem if it's a typed allocation/access, but I'm not particularly confident in that :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anyone got a 64-bit address space computer lying around to find out?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not entirely sure what is even meant by "object".

Honestly I'm also not completely confident... I think allocation is what is meant?

I was pretty much just rolling with it because "we have a slightly wibbly definition of 'object' deep in the codegen backend" feels kinda low on our list of concerns. Relatively speaking.

@workingjubilee
Copy link
Member Author

I have no idea what's up with the failing test and it looks like nobody else knows eithe.r

@workingjubilee
Copy link
Member Author

I'm going to give this one retry before I sit down with that test and have a nice long chat with it.

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 21, 2024
@workingjubilee
Copy link
Member Author

hm wait that might not be the right commit. @bors r=saethlin

@bors
Copy link
Collaborator

bors commented Sep 21, 2024

📌 Commit cf78f26 has been approved by saethlin

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Sep 21, 2024

⌛ Testing commit cf78f26 with merge 1d68e6d...

@bors
Copy link
Collaborator

bors commented Sep 21, 2024

☀️ Test successful - checks-actions
Approved by: saethlin
Pushing 1d68e6d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 21, 2024
@bors bors merged commit 1d68e6d into rust-lang:master Sep 21, 2024
7 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 21, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1d68e6d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.6% [-2.6%, -2.5%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.6% [-2.6%, -2.5%] 2

Cycles

Results (primary 0.8%, secondary 2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.8% [0.4%, 2.1%] 5
Regressions ❌
(secondary)
2.5% [2.5%, 2.5%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.8% [0.4%, 2.1%] 5

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.545s -> 769.527s (0.26%)
Artifact size: 341.42 MiB -> 341.45 MiB (0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants