Skip to content
This repository was archived by the owner on Apr 28, 2025. It is now read-only.

Some symbols reference libcore panicking functions #129

Closed
alexcrichton opened this issue Jul 24, 2018 · 0 comments · Fixed by #131
Closed

Some symbols reference libcore panicking functions #129

alexcrichton opened this issue Jul 24, 2018 · 0 comments · Fixed by #131

Comments

@alexcrichton
Copy link
Member

I was curious to give out the new libm-for-wasm bits a spin and got a small example working, but to my surprise it imported a few functions from the environment:

  (import "env" "_ZN4core9panicking18panic_bounds_check17h5517321e0731ca2aE" (func $core::panicking::panic_bounds_check::h5517321e0731ca2a (type $t0)))
  (import "env" "_ZN4core9panicking5panic17he062e0bd3417b514E" (func $core::panicking::panic::he062e0bd3417b514 (type $t1)))

which isn't good for wasm!

It looks like these are mostly around the rem_pio2_large function (and family of functions from the looks of it)

japaric added a commit that referenced this issue Jul 25, 2018
this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129
bors bot added a commit that referenced this issue Jul 25, 2018
131: omit bounds check in release mode r=japaric a=japaric

this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129

Co-authored-by: Jorge Aparicio <jorge@japaric.io>
bors bot added a commit that referenced this issue Jul 25, 2018
131: omit bounds check in release mode r=japaric a=japaric

this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129

Co-authored-by: Jorge Aparicio <jorge@japaric.io>
bors bot added a commit that referenced this issue Jul 25, 2018
131: omit bounds check in release mode r=japaric a=japaric

this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129

Co-authored-by: Jorge Aparicio <jorge@japaric.io>
@bors bors bot closed this as completed in #131 Jul 25, 2018
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jul 26, 2018
bors added a commit to rust-lang/rust that referenced this issue Jul 27, 2018
…richton

Update the compiler-builtins submodule

Pull in a fix for rust-lang/libm#129
tgross35 pushed a commit that referenced this issue Apr 18, 2025
this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129
tgross35 pushed a commit that referenced this issue Apr 18, 2025
131: omit bounds check in release mode r=japaric a=japaric

this eliminates panicking branches in the optimized version of the functions. We keep the bounds
checks when running the test suite to check that we never do an out of bounds access.

This commit also adds a "must link" test that ensures that future changes in our implementation
won't add panicking branches.

closes #129

Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant