-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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.
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
Fix target_env
in avr-unknown-gnu-atmega328
#131171
Conversation
The target name itself contains GNU, we should set that in the environment as well.
These commits modify compiler targets. |
My understanding at present is that if these AVR targets contain specific ABI-affecting codegen options / target features differences, including |
I believe |
Thanks for the clarification; IMO, that sounds like a bug in |
This is a known general class of problems where we should indeed be tracking ABI-affecting target features / codegen options and detecting if we're trying to (You can search the issue tracker for |
cc @Rahix |
I'll add that this is especially relevant now for |
rustc supports arbitrary target specs, albeit not stable, so AFAIK you might have to do something like rust/src/tools/compiletest/src/common.rs Line 496 in 5384697
Not sure exactly about your use case in |
I meant, |
I think this is correct from my point of view. But just in case, cc @Patryk27 as he's way better versed in the details of the AVR target than me :)
So this is something that seems to have flown past me completely. I'll have to have a play with it to see if |
r? compiler |
Cool! I've opened Rahix/avr-hal#586 to track it in a more appropriate place than this PR, sorry for the indirection. |
I'm not sure on the original design, but I'd be up for using just |
I can't speak for T-compiler here, but I suspect that they'd be fine with a |
while also not capable of speaking with The Voice Of An Entire Team, if we had some folks sign up to be AVR maintainers officially, I think we'd be happy to be merge whatever small compiler changes are necessary. frankly, we'd finally have someone to stick with the caseload of AVR weirdness and making decisions on what is and is not a bug. |
Sure, I've been handling AVR bugs for quite a while now and I don't mind doing it officially 🙂 |
Nice! Could you file a PR that adds I can also do it myself, but I think you know a lot more about the target, so you're probably better suited for providing the information. |
@bors r+ rollup |
…kingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#130453 (Add x86_64-unknown-trusty as tier 3 target) - rust-lang#130518 (Stabilize the `map`/`value` methods on `ControlFlow`) - rust-lang#131116 (Increase Stack Size for AIX) - rust-lang#131171 (Fix `target_env` in `avr-unknown-gnu-atmega328`) - rust-lang#131174 (Fix `target_abi` in `sparc-unknown-none-elf`) - rust-lang#131177 ( Stabilize 5 `const_mut_refs`-dependent API) - rust-lang#131238 (Remove mw from triagebot.toml) - rust-lang#131240 (Fix typo in csky-unknown-linux-gnuabiv2.md) - rust-lang#131257 ([rustdoc] Fix list margins) - rust-lang#131264 (Fix some `pub(crate)` that were undetected bc of `#[instrument]`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#131171 - madsmtm:target-info-avr-env, r=petrochenkov Fix `target_env` in `avr-unknown-gnu-atmega328` The target name itself contains GNU, we should probably reflect that as `target_env = "gnu"` as well? Or from my reading of rust-lang#74941 (comment), perhaps not, but then that should probably be documented somewhere? There's no listed target maintainer, but the target was introduced in rust-lang#74941, so I'll ping the author of that: `@dylanmckay` Relatedly, I wonder _why_ the recommendation is to [create separate target triples for each AVR](https://github.com/Rahix/avr-hal/tree/main/avr-specs), when `-Ctarget-cpu=...` would suffice, perhaps you could also elaborate on that? Was it just because `-Ctarget-cpu=...` didn't exist back then? If so, now that it does, should we now change the target back to e.g. `avr-unknown-none-gnu`, and require the user to set `-Ctarget-cpu=...` instead?
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-unknown-unknown` variant that can be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). I've decided to go with the `-unknown` tag (i.e. `avr-unknown-unknown` instead of `avr-unknown-gnu`), because that's the name LLVM already uses - I see no reason to diverge here. Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official. Related discussion: rust-lang#131171
The target name itself contains GNU, we should probably reflect that as
target_env = "gnu"
as well? Or from my reading of #74941 (comment), perhaps not, but then that should probably be documented somewhere?There's no listed target maintainer, but the target was introduced in #74941, so I'll ping the author of that: @dylanmckay
Relatedly, I wonder why the recommendation is to create separate target triples for each AVR, when
-Ctarget-cpu=...
would suffice, perhaps you could also elaborate on that? Was it just because-Ctarget-cpu=...
didn't exist back then? If so, now that it does, should we now change the target back to e.g.avr-unknown-none-gnu
, and require the user to set-Ctarget-cpu=...
instead?