Skip to content

Add float quickcheck #111

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

Merged
merged 3 commits into from
Nov 13, 2016
Merged

Conversation

mattico
Copy link
Contributor

@mattico mattico commented Oct 16, 2016

No description provided.

Copy link
Member

@japaric japaric left a comment

Choose a reason for hiding this comment

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

I had already review this but there are some changes that are needed to not include the intrinsics that are failing their tests (for the arm-unknown-linux-gnueabi target only).

a: F32,
b: F32)
-> Option<F32> {
if option_env!("TARGET") != Some("arm-unknown-linux-gnueabi") {
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't seem to be working; Travis is still failing this test.

Could you instead #[cfg] away the addsf3 and adddf3 symbols along with these too tests for the arm-unknown-linux-gnueabi? And please add a comment about the problem and point to the issue that's tracking it #90

// just avoid testing against gcc_s on those targets. Do note that our
// implementation matches the output of the FPU instruction on *hard* float targets
// and matches its gcc_s counterpart on *soft* float targets.
if cfg!(gnueabihf) {
Copy link
Member

Choose a reason for hiding this comment

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

Is this still necessary? There's now a FRepr struct wrapper for this logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was meant to replace FRepr, but I forgot to do that when rebasing.

@mattico mattico force-pushed the new_float_quickcheck branch 2 times, most recently from fee97fa to 585d6ed Compare October 16, 2016 22:46
@mattico
Copy link
Contributor Author

mattico commented Oct 16, 2016

I hope you don't have build failure emails turned on 😉. I think I fixed everything now...

@japaric
Copy link
Member

japaric commented Oct 16, 2016

I hope you don't have build failure emails turned on 😉.

Oh, they are enabled but they aren't reaching my mailbox which probably means they are being sent to the rust-lang org mailbox 😄.

@mattico mattico force-pushed the new_float_quickcheck branch from 585d6ed to 3e7fb1f Compare October 16, 2016 23:13
@@ -181,117 +181,30 @@ macro_rules! add {
}
}

// NOTE(cfg) These are disabled for gnueabihf due to
// https://github.com/rust-lang-nursery/compiler-builtins/issues/90
#[cfg(not(gnueabi))]
Copy link
Member

Choose a reason for hiding this comment

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

Right now, cfg(gnueabihf) works but cfg(gnueabi) doesn't. You'll have to update the build.rs to make Cargo pass this cfg when the target is arm-unknown-linux-gnueabi. See https://github.com/rust-lang-nursery/compiler-builtins/blob/master/build.rs#L428

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So should the addsf3.c files be enabled for arm-unknown-linux-gnueabi since we're disabling the rust version?

Copy link
Member

Choose a reason for hiding this comment

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

yes

@mattico
Copy link
Contributor Author

mattico commented Oct 27, 2016

Oops, I've been neglecting this. Will update.

@mattico mattico force-pushed the new_float_quickcheck branch from 3e01b2e to 6d6dbdc Compare November 3, 2016 02:32
@japaric
Copy link
Member

japaric commented Nov 8, 2016

@bors r+

Thank you, @mattico

@bors
Copy link
Contributor

bors commented Nov 8, 2016

📌 Commit 6504950 has been approved by japaric

@bors
Copy link
Contributor

bors commented Nov 8, 2016

⌛ Testing commit 6504950 with merge e871d09...

bors added a commit that referenced this pull request Nov 8, 2016
@bors
Copy link
Contributor

bors commented Nov 8, 2016

💥 Test timed out

@japaric
Copy link
Member

japaric commented Nov 8, 2016

@alexcrichton The tests seemed to pass (they are "green") but bors/homu didn't merge it.

@alexcrichton
Copy link
Member

@bors: retry force clean

Your guess is as good as mine...

@alexcrichton
Copy link
Member

@bors: retry clean

@bors
Copy link
Contributor

bors commented Nov 11, 2016

⌛ Testing commit 6504950 with merge 93babe2...

bors added a commit that referenced this pull request Nov 11, 2016
@bors
Copy link
Contributor

bors commented Nov 12, 2016

💥 Test timed out

@japaric
Copy link
Member

japaric commented Nov 12, 2016

@alexcrichton Time out again. Maybe something got misconfigured (the webhook?).

@alexcrichton
Copy link
Member

Hm so recently I reclassified the appveyor repo to run under a different account, and I've been seeing these same timeout problems on the libc repo as well.

Unfortunately I have no idea why they're happening... Appveyor/Travis are green though, so want to merge?

@japaric
Copy link
Member

japaric commented Nov 12, 2016

Hm so recently I reclassified the appveyor repo to run under a different account, and I've been seeing these same timeout problems on the libc repo as well.

Perhaps you should try removing the existing appveyor webhooks (this repo > settings > webhooks) and re-adding the projects on appveyor.

Appveyor/Travis are green though, so want to merge?

👍 from me.

@alexcrichton
Copy link
Member

Let's try that one more time...

@bors: retry

bors added a commit that referenced this pull request Nov 12, 2016
@bors
Copy link
Contributor

bors commented Nov 12, 2016

⌛ Testing commit 6504950 with merge 14ed7ef...

@mattico
Copy link
Contributor Author

mattico commented Nov 12, 2016

Hm, looking at this now I think I should unify the handling of *-gnueabi and *-gnueabihf since (AFAIK) the error is the same in both cases. That is, for both targets:

  • Continue to use the rust add implementation since it gives correct answers
  • Disable tests for the add impl on *-gnueabi* since compiler-rt and gcc_s give incorrect answers sometimes (I still haven't figured out why).

If this PR gets merged before you see this, I'll just make a follow-up PR.

@mattico
Copy link
Contributor Author

mattico commented Nov 12, 2016

This probably won't work but:
@bors r-

@japaric
Copy link
Member

japaric commented Nov 12, 2016

@bors r-

@japaric
Copy link
Member

japaric commented Nov 12, 2016

I think bors is not listening to me either...

@japaric
Copy link
Member

japaric commented Nov 12, 2016

but it seems bors got stuck again anyway so this won't get merged.

@mattico mattico force-pushed the new_float_quickcheck branch from 6504950 to 655f642 Compare November 12, 2016 21:00
@mattico
Copy link
Contributor Author

mattico commented Nov 12, 2016

Ok this is much better now. It's simpler, and now the powi tests will still run on gnueabi.

if llvm_target.last() == Some(&"gnueabihf") {
println!("cargo:rustc-cfg=gnueabihf")
if llvm_target.last().unwrap().contains("gnueabi") {
println!("cargo:rustc-cfg=gnueabi")
Copy link
Member

Choose a reason for hiding this comment

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

Could you use two cfgs here, gnueabi and gnueabihf, instead of overloading the word "gnueabi" to mean both ABIs? I think it would be less error prone that way.

Copy link
Contributor Author

@mattico mattico Nov 12, 2016

Choose a reason for hiding this comment

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

Hm. Good point. This also accidentally disables the tests on armv7-* which doesn't seem to have this issue (does it?).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nevermind, armv7-* also has this issue.

println!("cargo:rustc-cfg=gnueabi")
if llvm_target[0].starts_with("arm") &&
llvm_target.last().unwrap().contains("gnueabi") {
println!("cargo:rustc-cfg=arm-linux")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@japaric is this better?

@mattico mattico force-pushed the new_float_quickcheck branch from 691782d to f68475e Compare November 12, 2016 21:53
@japaric
Copy link
Member

japaric commented Nov 12, 2016

@bors r+

Thanks, @mattico.

@bors
Copy link
Contributor

bors commented Nov 12, 2016

📌 Commit f68475e has been approved by japaric

@bors
Copy link
Contributor

bors commented Nov 12, 2016

⌛ Testing commit f68475e with merge c459e19...

bors added a commit that referenced this pull request Nov 12, 2016
@mattico
Copy link
Contributor Author

mattico commented Nov 12, 2016

🍀

@japaric
Copy link
Member

japaric commented Nov 13, 2016

Stuck again but I'm going to merge manually.

@japaric japaric merged commit 8992316 into rust-lang:master Nov 13, 2016
@mattico mattico deleted the new_float_quickcheck branch November 13, 2016 02:23
tgross35 pushed a commit to tgross35/compiler-builtins that referenced this pull request Feb 23, 2025
111: Implement tanh r=japaric a=porglezomp

Closes rust-lang#37

Co-authored-by: C Jones <code@calebjones.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants