Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Set max_atomic_width for riscv32*-esp-espidf to 32 #117307

Merged
merged 1 commit into from
Nov 1, 2023
Merged

Set max_atomic_width for riscv32*-esp-espidf to 32 #117307

merged 1 commit into from
Nov 1, 2023

Conversation

taiki-e
Copy link
Member

@taiki-e taiki-e commented Oct 28, 2023 •
edited
Loading

Fixes #117305

Since riscv32 does not have 64-bit atomic instructions, I do not believe there is any way to fix this problem other than setting max_atomic_width of these targets to 32.

This is a breaking change because Atomic*64 will become unavailable, but all affected targets are tier 3, and the current Atomic*64 violates the standard library's API contract and can cause problems with code that rely on the standard library's atomic types being lock-free.

r? @Amanieu
cc @ivmarkov @MabezDev

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 28, 2023
@rustbot
Copy link
Collaborator

rustbot commented Oct 28, 2023

These commits modify compiler targets.
(See the Target Tier Policy.)

@workingjubilee workingjubilee mentioned this pull request Oct 28, 2023
Closed
MabezDev
MabezDev approved these changes Oct 28, 2023
View reviewed changes
Copy link
Contributor

@MabezDev MabezDev left a comment

Choose a reason for hiding this comment

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

From a brief look around the ecosystem, there is better support for 32-bit targets now. tokio was a main concern of mine, but it looks like that should now work with 32-bit targets ootb. There could be an argument to leave the imc target unchanged as only single-core variants exist, but I think it's best to keep them in sync.

LGTM.

@Amanieu
Copy link
Member

Amanieu commented Oct 31, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Oct 31, 2023

📌 Commit ecefd4e has been approved by Amanieu

It is now in the queue for this repository.

@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 Oct 31, 2023
@bors
Copy link
Contributor

bors commented Nov 1, 2023

⌛ Testing commit ecefd4e with merge f683e8b...

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 1, 2023
@bors
Auto merge of rust-lang#117307 - taiki-e:espidf-atomic-64, r=Amanieu
f683e8b 
Set max_atomic_width for riscv32*-esp-espidf to 32

Fixes rust-lang#117305

> Since riscv32 does not have 64-bit atomic instructions, I do not believe there is any way to fix this problem other than setting max_atomic_width of these targets to 32.

This is a breaking change because Atomic\*64 will become unavailable, but all affected targets are tier 3, and the current Atomic*64 violates the standard library's API contract and can cause problems with code that rely on the standard library's atomic types being lock-free.

r? `@Amanieu`
cc `@ivmarkov` `@MabezDev`
@bors
Copy link
Contributor

bors commented Nov 1, 2023

💔 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 Nov 1, 2023
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@taiki-e
Copy link
Member Author

taiki-e commented Nov 1, 2023 •
edited
Loading 

 Step 1/10 : FROM ubuntu:22.04
  error parsing HTTP 429 response body: invalid character 'T' looking for beginning of value: "Too Many Requests (HAP429).\n"

It seems to be a docker-related network error. (Unrelated to this PR's change.)

@Amanieu
Copy link
Member

Amanieu commented Nov 1, 2023

@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 Nov 1, 2023
@bors
Copy link
Contributor

bors commented Nov 1, 2023

⌛ Testing commit ecefd4e with merge f3457db...

@bors
Copy link
Contributor

bors commented Nov 1, 2023

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing f3457db to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 1, 2023
@bors bors merged commit f3457db into rust-lang:master Nov 1, 2023
11 checks passed
@rustbot rustbot added this to the 1.75.0 milestone Nov 1, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (f3457db): 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

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)		 2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)		 1.4% [1.4%, 1.4%] 1
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 2.3% [2.3%, 2.3%] 1

Cycles

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

Binary size

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

Bootstrap: 638.45s -> 638.227s (-0.03%)
Artifact size: 304.48 MiB -> 304.50 MiB (0.01%)

@taiki-e taiki-e deleted the espidf-atomic-64 branch November 1, 2023 20:03
@github-actions github-actions bot mentioned this pull request Nov 2, 2023
Merged
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Nov 2, 2023
@bors-ferrocene @devnexen
@taiki-e @clarfonthey @rmehri01
Merge #80
0800006 
80: Automated pull from upstream `master` r=tshepang a=github-actions[bot]


This PR pulls the following changes from the upstream repository:

* rust-lang/rust#117498
  * rust-lang/rust#117488
  * rust-lang/rust#117441
  * rust-lang/rust#117373
  * rust-lang/rust#117298
* rust-lang/rust#117029
* rust-lang/rust#117289
* rust-lang/rust#117307
* rust-lang/rust#114208
* rust-lang/rust#117482
  * rust-lang/rust#117475
  * rust-lang/rust#117401
  * rust-lang/rust#117397
  * rust-lang/rust#115626
* rust-lang/rust#117436
* rust-lang/rust#115356
* rust-lang/rust#117422
* rust-lang/rust#116692



Co-authored-by: David CARLIER <devnexen@gmail.com>
Co-authored-by: Taiki Endo <te316e89@gmail.com>
Co-authored-by: ltdk <usr@ltdk.xyz>
Co-authored-by: Ryan Mehri <ryan.mehri1@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@MabezDev MabezDev MabezDev approved these changes

Assignees

@Amanieu Amanieu

Labels
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-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.75.0
Development

Successfully merging this pull request may close these issues.

ESP-IDF targets' Atomic*64 is not lock-free
7 participants
@taiki-e @rustbot @Amanieu @bors @rust-log-analyzer @rust-timer @MabezDev