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.

Sign up for GitHub

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

Jump to bottom

Consider using an embedded libm #10774

Closed
emberian opened this issue Dec 2, 2013 · 6 comments
Closed

Consider using an embedded libm #10774

emberian opened this issue Dec 2, 2013 · 6 comments

Comments

@emberian
Copy link
Member

emberian commented Dec 2, 2013

For performance and consistency reasons, we might want to bundle our own libm. It further reduces our dependency on system libraries, opens the potential for LTO, and gives us something we can control and define.

A good candidate is openlibm, which has a long history.

See #5702, #1222
@emberian
Copy link
Member Author

emberian commented Dec 2, 2013

Unless there are objections, I plan on using openlibm.

@brendanzab
Copy link
Member

I don't know enough about it to make any comment, but I do think it would be awesome if the libm functionality was rewritten in Rust. But this might be reasonable in the short term. cc. @jensnockert

@thestinger
Copy link
Contributor

I think we should support alternate math libraries, but I don't think we should be embedding any more libraries.

@emberian
Copy link
Member Author

There was also a discussion on IRC; I'm convinced that this is a bad idea.

@thestinger thestinger reopened this Feb 2, 2014
@thestinger
Copy link
Contributor

I'm re-opening this, because I think it's going to be necessary if we want to keep using the LLVM math intrinsics. These intrinsics assume errno is not set on errors so LLVM may reorder them in a way that would clobber another errno value before it is read.

@thestinger thestinger mentioned this issue May 13, 2014
Closed
40 tasks
@steveklabnik steveklabnik mentioned this issue Jan 23, 2015
Open
@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#711

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
@bors
Auto merge of rust-lang#10774 - c410-f3r:lock-1, r=Jarcho
73f1417 
[significant_drop_tightening] Fix rust-lang#10413

Fix rust-lang#10413

This is quite a rewrite that unfortunately took a  large amount of time. I tried my best to comment what is going on to easy review but feel free to ask any question.

The problem basically is that the current algorithm is only taking into consideration single blocks which means that things like the following don't work or show unpredictable results.

```rust
let mutex = Mutex::new(1);
{
  let lock = mutex.lock().unwrap();
  {
    let _ = *lock;
  }
}
```

The solve the issue, each path that refers a lock is now being tracked individually.

```
changelog: [`significant_drop_tightening`]: Lift the restriction of only considerate single blocks
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @brendanzab @emberian @thestinger