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.

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

add test: cross compiling core for no_std targets #38828

Open
japaric opened this issue Jan 4, 2017 · 5 comments
Open

add test: cross compiling core for no_std targets #38828

japaric opened this issue Jan 4, 2017 · 5 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems

Comments

@japaric
Copy link
Member

japaric commented Jan 4, 2017

For these targets

  • thumbv6m-none-eabi
  • thumbv7m-none-eabi
  • thumbv7em-none-eabi
  • thumbv7em-none-eabihf
  • nvptx-nvidia-cuda
  • msp430-none-elf
  • msp430x-none-elf
  • nvptx64-nvidia-cuda

These targets have zero tests in tree. Let's at least test cross compiling core for them to catch LLVM / codegen related regressions.

This would have catched #38824 before it landed in master.

cc @alexcrichton @brson Does a run-make test sounds OK for this? Do we have at least one bot configured with --enable-llvm-assertions?

@japaric japaric added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Jan 4, 2017
@alexcrichton
Copy link
Member

If we commit to compiling core for these targets then we're essentially moving them to tier 2, which will come at a cost. I'm not sure I would have wanted to block the i128 PR personally on msp430 support, personally.

If we do want to make these tier 2 we can figure out a strategy for doing so, but I think that we should decide first if we do want to move them to tier 2 (cc @rust-lang/tools)

@est31
Copy link
Member

est31 commented Jan 4, 2017

These listed platforms are tier 3 ones, they are not guaranteed to build. Gating master on them bears a risk to make big changes to the codebase like the i128 PR even harder as it is already now. E.g. discovering this issue would have meant yet another week where the i128 PR sits in limbo, where it has to be rebased once again, and fixed once again, wait for bors queue to clean up, maybe release being too close and therefore paused again, etc. etc.

However, I'm okay with added tests as long as its easy to reproduce the issue locally (which seems to be the case for a run-make test, where you don't need to download strange compilers, or operating systems), and as long as help from experts on those targets is provided. I for example didn't know that removing i128 for these targets was a legal way to fix the issue.

@alexcrichton
Copy link
Member

Discussed during tools triage the other week our conclusion was:

  • Seems good to add testing/building of libcore for the thumb targets for now
  • We should update the forget to reflect tier 3 status of the various platforms

japaric pushed a commit to japaric/rust that referenced this issue Apr 7, 2017
this commit adds a new path, src/libcore, to bootstrap that (cross) compiles
only the core crate for the target, and a thumb image that will test cross
compiling core for the 4 existing thumb targets.

closes rust-lang#38828
@Mark-Simulacrum Mark-Simulacrum added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@jonas-schievink jonas-schievink added the WG-embedded Working group: Embedded systems label Nov 9, 2019
@jonas-schievink jonas-schievink added the A-testsuite Area: The testsuite used to check the correctness of rustc label Jan 15, 2020
@jonas-schievink
Copy link
Contributor

Triage:

@workingjubilee
Copy link
Member

A compromise variant of this, of sorts, which checks if-anything-builds-at-all, will be added as part of implementing rust-lang/compiler-team#655 after which this can be closed.

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 C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants