-
Notifications
You must be signed in to change notification settings - Fork 221
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 an opt-in cargo feature to build intrinsics from compiler-rt source #74
Conversation
@homunkulus try |
💔 Test failed - status-travis |
@japaric I'd personally prefer to keep the dependencies of the rust-lang/rust repo as slim as possible, and in that sense calling |
does that include dev dependencies? This repo uses quickcheck for its tests. |
Also, |
@homunkulus try |
💔 Test failed - status-travis |
@alexcrichton having that intrinsics.rs test in this repository has helped me a lot in debugging issues with missing/undefined symbols. Thanks to it I just learned that the I'm actually wondering if it's actually necessary to also run the intrinsics.rs test on the rust-lang/rust repo. Seems like all intrinsics related changes would have to first go through this repository and the CI + intrinsics.rs in this repo should catch any problem as long as we are testing all tier 1 targets (I think I'm only missing android atm) and the intrinsics.rs file covers all the relevant operations (right now, it covers ~70 intrinsics). |
@homunkulus try |
💔 Test failed - status-travis |
@homunkulus try OK. This should be ready to go now. Who wants to review? @Amanieu @mattico The build.rs addition is pretty much a copy paste of the one from rust-lang/rust#36512 with additional changes to support the thumb* targets. I should have done that part in two commits so the additional changes were more obvious, sorry; but all the additions should have a "thumb" string near to it :-). |
I'll take a look. |
💔 Test failed - status-appveyor |
Looks like we ran into the gist rate limit on the CI, should be pretty easy to fix. |
Oh right, I have to update the AppVeyor CI to test these changes. I'll probably have to use ugh powershell so I'm going to leave that for a follow-up PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some thoughts about link args for the intrinsics link test. Everything else looks good to me.
$CARGO clean | ||
|
||
# verify we haven't drop any intrinsic/symbol | ||
$CARGO build --features c --target $TARGET --bin intrinsics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to have RUSTFLAGS="-C link-args='-Wl,-nostartfiles -Wl,-nodefaultlibs'"
so that it applies to all targets? I'm assuming that we don't need libc anywhere in there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only -nostartfiles is needed on Linux. I think that would work on Linux, but idk about OSX and Windows. I'm using the libc crate because, on each platform, it links to different libraries needed to produce an executable. Without it the executable may not link at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good 👍. In any case it doesn't make much of a difference.
"features": "+strict-align", | ||
"llvm-target": "thumbv6m-none-eabi", | ||
"max-atomic-width": 0, | ||
"os": "none", | ||
"pre-link-args": ["-nostartfiles"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, we wouldn't need these anymore.
@homunkulus try This should be ready to go. @alexcrichton Mind taking a look at the changes in the testing infra? Also, are you OK with adding rust-cfg here or would you prefer to just use $TARGET and |
@homunkulus try |
@homunkulus try |
|
||
fn main() { | ||
if env::var("TARGET").unwrap().ends_with("gnueabihf") { | ||
println!("cargo:rerun-if-changed=build.rs"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is compiling a bunch of C files then this'll probably also want to print a similar key for those files as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gcc-rs doesn't generate those for me?
// NOTE Most of the ARM intrinsics are written in assembly. Tell gcc which arch we are going to | ||
// target to make sure that the assembly implementations really work for the target. If the | ||
// implementation is not valid for the arch, then gcc will error when compiling it. | ||
if llvm_target[0].starts_with("thumb") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this logic be added to gcc-rs? (it'll be needed for any C code, right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's fine to add logic for targets that are not built into the compiler then I can send a PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah that's true, but it's looking like we'll add these soon so I wouldn't mind adding them.
thumb*) | ||
PREFIX=arm-none-eabi- | ||
;; | ||
*-unknown-linux-gnu | *-apple-darwin) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this'll catch mips/mipsel/powerpc, right? (is that intended?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah no. I meant to only pick up x86-ish targets. I'll fix it.
Sure!
I think we'll end up adding this no matter what, so seems good to me! |
@alexcrichton I've addressed all your comments I think. |
Minus the gcc-rs bit because that will take time to land and we can always remove the gcc flags for thumb* later on |
xargo build --features c --target $1 --bin intrinsics | ||
;; | ||
*) | ||
cargo build --features c --target $1 --bin intrinsics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this build could also be tested as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo test --features c
would end testing the same thing I think. We'll just be testing less intrinsics on some targets. Also, this would require sprinkling more cfg over the test modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, carry on then!
// convention for its intrinsics that's different from other architectures; that's why some function | ||
// have an additional comment: the function name is the ARM name for the intrinsic and the comment | ||
// in the non-ARM name for the intrinsic. | ||
#[cfg(feature = "c")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of these are defined even when feature=c is disabled, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to test those in the cfg(not(feature = "c")) main?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory yeah, but it's fine to land this ahead of time.
Looking good to me! The |
Let's get rid of the C code fast so we can soon get rid of all these cfgs and the C feature as well! |
Agreed! |
@homunkulus r+ Alright, let's land this. Then I can try landing this in rust-lang/rust, which is probably going to be awful |
📌 Commit 61484ac has been approved by |
💔 Test failed - status-travis |
Did https://static.rust-lang.org/rustup.sh break? All the |
I think? But claimed to be fixed. Maybe it's not though? |
@homunkulus retry |
@homunkulus r+ |
📌 Commit cab88e6 has been approved by |
☀️ Test successful - status-appveyor, status-travis |
74: Implement roundf r=japaric a=P1n3appl3 closes rust-lang#32 Co-authored-by: Joseph Ryan <[email protected]>
closes #63
cc #66
This uses the build.rs version from rust-lang/rust#36512 minus the dependency on llvm-target being in
rustc --print cfg
cc @alexcrichton I forgot to ask before but how do you feel about using the
rustc-cfg
crate, which parses the output ofrustc --print cfg
and exposes the target specification as a Ruststruct
, in the build.rs? Its functionality overlaps with what you proposed in rust-lang/rfcs#1721 i.e. CARGO_CFG_TARGET_OS, etc.TODO stop compiling the C version of the intrinsics that we have already ported to Rust.