Add avr_target_feature by taiki-e · Pull Request #146900 · rust-lang/rust

taiki-e · 2025-09-22T17:42:22Z

This adds the following unstable target features (tracking issue: #146889):

The following two are particularly important for properly supporting inline assembly:
- tinyencoding: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also Support AVRTiny devices in AVR inline assembly #146901)
- lowbytefirst: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876)
The followings help recognizing whether specific instructions are available:
- addsubiw
- break
- eijmpcall
- elpm
- elpmx
- ijmpcall
- jmpcall
- lpm
- lpmx
- movw
- mul
- rmw
- spm
- spmx
Of these, all except addsubiw, break, ijmpcall, lpm, rmw, spm, and spmx have corresponding conditional codes in avr-libc. LLVM also has des feature, but I excluded it from this PR because DES is insecure.
Report future-incompatible warning (The ABI of float types can be changed by -Ctarget-feature #116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM.
- See Add avr_target_feature #146900 (comment) for details.

LLVM also has smallstack, wrappingrjmp, and memmappedregs features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something.

(The feature names are match with definitions in LLVM.)

cc @Patryk27 @Rahix
r? workingjubilee

@rustbot label +O-AVR +A-target-feature

rustbot · 2025-09-22T17:42:28Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

taiki-e · 2025-09-23T11:15:56Z

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

Patryk27 · 2025-09-23T16:45:57Z

compiler/rustc_target/src/target_features.rs

+static AVR_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[
+    // tidy-alphabetical-start
+    ("addsubiw", Unstable(sym::avr_target_feature), &[]),
+    ("break", Unstable(sym::avr_target_feature), &[]),


nit: what about name collisions? 👀

The RFC doesn't seem to mention this, but I can see AVR's break (or other "generic" word like mul) accidentally colliding with another arch in future - on the other hand, keeping the mapping 1:1 with LLVM (FeatureBREAK in this case) is important as well, IMO.

Other than that LGTM.

Target feature name collisions with other architectures are fine. (e.g., the aes target feature exists on x86/x86_64 (AES-NI) and arm/aarch64/arm64ec (FEAT_AES) respectively.)

taiki-e · 2025-09-24T14:37:33Z

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

Looking at the LLVM issue, in Rust, I guess it might work if we use no_main and put all processing inside global_asm and/or external assemblies...

workingjubilee · 2025-09-27T23:20:48Z

cc @rust-lang/lang informational-only: letting you know about this target's features because it is particularly interesting in terms of it being on the boundary of what Rust can support.

I think that we should indeed either ignore it or just error if someone tries to say -Ctarget-feature=-sram to the compiler. It is a rare case of "Here's a nickel, kid, go buy yourself a real computer" being an actually literally valid suggestion, even with 2025's inflation. The newest "AVR1" chips are so old that even products with 25-year lifecycles should have killed them off by now.

bors · 2025-11-05T08:32:15Z

☔ The latest upstream changes (presumably #147645) made this pull request unmergeable. Please resolve the merge conflicts.

workingjubilee · 2025-11-15T20:15:34Z

This is waiting on "-sram should error", I think?

@rustbot author

rustbot · 2026-01-09T01:43:42Z

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

taiki-e · 2026-01-09T14:52:54Z

Changed sram to Forbidden and added it to abi_required_features, to report future-incompatible warning (#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases.

@rustbot ready

rust-bors · 2026-01-15T00:58:34Z

☔ The latest upstream changes (presumably #151144) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot · 2026-01-15T02:06:08Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

workingjubilee · 2026-02-04T21:30:41Z

T-lang has to approve these features being stable, last I checked, but I believe we can accept this for now as this is unstable and the same "eh, let's throw them in" basis was used for the initial add of every other architecture's features.

@bors r+

rust-bors · 2026-02-04T21:30:44Z

📌 Commit febe008 has been approved by workingjubilee

It is now in the queue for this repository.

workingjubilee · 2026-02-04T21:31:49Z

tests/ui/abi/avr-sram.disable_sram.stderr

+warning: target feature `sram` cannot be disabled with `-Ctarget-feature`: devices that have no SRAM are unsupported
+   |
+   = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+   = note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
+
+warning: target feature `sram` must be enabled to ensure that the ABI of the current target can be implemented correctly
+   |
+   = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+   = note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
+
+warning: 2 warnings emitted
+


This should probably proactively become a hard error before stabilizing.

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

Rollup of 15 pull requests Successful merges: - #151431 (Add new unstable attribute: `#[export_visibility = ...]`.) - #146900 (Add avr_target_feature) - #152033 (Rename trait `DepNodeParams` to `DepNodeKey`) - #152142 (Convert to inline diagnostics in `rustc_hir_typeck`) - #152020 (Remove dummy loads on offload codegen) - #152023 (Some `rustc_query_system` cleanups) - #152068 (Convert to inline diagnostics in `rustc_resolve`) - #152081 (Port depgraph testing attributes to parser) - #152090 (Port reexport_test_harness_main to attr parser) - #152105 (Convert to inline diagnostics in `rustc_ast_lowering`) - #152108 (Convert to inline diagnostics in `rustc_expand`) - #152114 (Convert to inline diagnostics in `rustc_mir_transform`) - #152115 (Convert to inline diagnostics in `rustc_metadata`) - #152116 (Remove rustdoc GUI flaky test) - #152128 (Adopt matches-logical-or-141497.rs to LLVM HEAD) Failed merges: - #152070 (Convert to inline diagnostics in `rustc_pattern_analysis`) - #152106 (Convert to inline diagnostics in `rustc_ast_passes`) - #152109 (Convert to inline diagnostics in `rustc_errors`) - #152117 (Convert to inline diagnostics in `rustc_trait_selection`) - #152118 (Convert to inline diagnostics in `rustc_codegen_ssa`) - #152119 (Convert to inline diagnostics in `rustc_middle`) - #152126 (Convert to inline diagnostics in `rustc_mir_build`) - #152131 (Port rustc_no_implicit_bounds attribute to parser.)

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

rustbot assigned workingjubilee Sep 22, 2025

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 Sep 22, 2025

rustbot added A-target-feature Area: Enabling/disabling target features like AVX, Neon, etc. O-AVR Target: AVR processors (ATtiny, ATmega, etc.) labels Sep 22, 2025

This was referenced Sep 22, 2025

Tracking Issue for avr_target_feature #146889

Open

Support AVRTiny devices in AVR inline assembly #146901

Draft

Patryk27 reviewed Sep 23, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 15, 2025

taiki-e force-pushed the avr-target-feature branch from 18d8866 to 7763f18 Compare January 9, 2026 01:43

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avr-target-feature branch from 7763f18 to e3f2d28 Compare January 9, 2026 01:51

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avr-target-feature branch 2 times, most recently from 0d13763 to 75de66b Compare January 9, 2026 13:38

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 9, 2026

Add avr_target_feature

359854d

taiki-e force-pushed the avr-target-feature branch from 75de66b to e940165 Compare January 15, 2026 02:06

Require sram target feature on AVR

febe008

taiki-e force-pushed the avr-target-feature branch from e940165 to febe008 Compare January 15, 2026 02:16

This comment has been minimized.

Sign in to view

rust-bors bot 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 Feb 4, 2026

workingjubilee reviewed Feb 4, 2026

View reviewed changes

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 15 pull requests #152144

Closed

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 18 pull requests #152147

Closed

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 19 pull requests #152149

Open

Uh oh!

Conversation

taiki-e commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 22, 2025

Uh oh!

taiki-e commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Patryk27 Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taiki-e Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

taiki-e commented Sep 24, 2025

Uh oh!

workingjubilee commented Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Nov 5, 2025

Uh oh!

workingjubilee commented Nov 15, 2025

Uh oh!

rustbot commented Jan 9, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

taiki-e commented Jan 9, 2026

Uh oh!

rust-bors bot commented Jan 15, 2026

Uh oh!

rustbot commented Jan 15, 2026

Uh oh!

This comment has been minimized.

workingjubilee commented Feb 4, 2026

Uh oh!

rust-bors bot commented Feb 4, 2026

Uh oh!

workingjubilee Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

taiki-e commented Sep 22, 2025 •

edited

Loading

taiki-e commented Sep 23, 2025 •

edited

Loading

Patryk27 Sep 23, 2025 •

edited

Loading

workingjubilee commented Sep 27, 2025 •

edited

Loading