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

switch to a current nightly #93

Merged
merged 2 commits into from
Oct 6, 2016
Merged

switch to a current nightly #93

merged 2 commits into from
Oct 6, 2016

Conversation

japaric
Copy link
Member

@japaric japaric commented Oct 6, 2016

No description provided.

@japaric
Copy link
Member Author

japaric commented Oct 6, 2016

@homunkulus r+

@homunkulus
Copy link
Contributor

📌 Commit 4df5deb has been approved by japaric

@homunkulus
Copy link
Contributor

⌛ Testing commit 4df5deb with merge 4df5deb...

@homunkulus
Copy link
Contributor

💔 Test failed - status-travis

@japaric
Copy link
Member Author

japaric commented Oct 6, 2016

@homunkulus try

@homunkulus
Copy link
Contributor

⌛ Trying commit 5908bb7 with merge 5908bb7...

@homunkulus
Copy link
Contributor

☀️ Test successful - status-appveyor, status-travis
State: approved= try=True

@japaric
Copy link
Member Author

japaric commented Oct 6, 2016

@mattico so, this is interesting. We are currently testing the arm-unknown-linux-gnueabi target with the nightly from 2016-09-21 and the all the tests pass. But in this PR, I tested the same arm target but vs today's nightly and it produces the failures you are seeing in #90 (see above, the first travis failure).

Now, the .travis.yml has a comment that says that we are using the older nightly for arm because of rust-lang/rust#36518 which, iirc, is the problem with u32 -> f32 u32 -> f64 being UB because those are intrinsics implemented in compiler-rt. Now, that particular issue supposedly has already been already fixed (rust-lang/rust#36828) but perhaps the fix is not yet in today's nightly.

@japaric
Copy link
Member Author

japaric commented Oct 6, 2016

@mattico Some things you could try to fix #90. Avoid doing a integer -> float (e.g. u32 -> f64) conversion. Maybe try directly generating random floating point values. Otherwise, you could try porting floatsidf and floatdidf to Rust so these tests end up using the Rust implementation rathern than compiler-rt's.

@japaric japaric merged commit 6726a8c into master Oct 6, 2016
@japaric japaric deleted the nightly-up branch October 6, 2016 04:01
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.

2 participants