Skip to content

Crash with lazy-initted vec #106

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
jyasskin opened this issue Jul 11, 2010 · 3 comments
Closed

Crash with lazy-initted vec #106

jyasskin opened this issue Jul 11, 2010 · 3 comments

Comments

@jyasskin
Copy link
Contributor

fn main() {
  let vec[int] later;
  if (true) {
    later = vec(1);
  } else {
    later = vec(2);
  }
  log later.(0);
}

crashes at runtime, apparently because the refcount of the new vector isn't getting incremented when it gets assigned to 'later'.

@graydon
Copy link
Contributor

graydon commented Jul 11, 2010

Refcount is being set, but typestate system is incorrectly judging the if and else block-ends to be the lifecycle-end of the slot 'later', so is dropping them there.

I see where the bug is (block-boundary is assuming init-in-block means owned-by-block) but it'll take a little fixing and I've got some more errands to do today. Will get at it. Thanks for the report.

@graydon
Copy link
Contributor

graydon commented Jul 12, 2010

Fix post-stmt drop calculations. Closed by b3cf793.

@graydon
Copy link
Contributor

graydon commented Jul 12, 2010

Fixed more correctly by 1843c99

mbrubeck pushed a commit to mbrubeck/rust that referenced this issue Oct 17, 2011
mbrubeck pushed a commit to mbrubeck/rust that referenced this issue Oct 17, 2011
mbrubeck pushed a commit to mbrubeck/rust that referenced this issue Oct 17, 2011
…r wrongness in the runtime. Sad times. Closes rust-lang#106 more correctly (and adds comment to explain).
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
This adds a strange macro, which I've replaced with a function, because it
seems there are not many better alternatives.

Also adds a test, and `#[allow(non_snake_case)]` to `#[simd_test]`.
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
* avx: _mm256_loadu_pd

* avx: _mm256_storeu_pd

* avx: _mm256_loadu_ps

* avx: _mm256_storeu_ps

* avx: fix _mm256_storeu_pd and _mm256_storeu_ps

* avx: _mm256_loadu_si256

* avx: _mm256_undefined_si256

* avx: _mm256_maskload_pd

* avx: _mm256_maskstore_pd

* Attempt to fix CI (rust-lang#108)

Need to bring codegen units back to only one for now

* [x86] sse4.2 add docs for _SIDD_EQUAL_RANGES (rust-lang#107)

- Add docs for the _SIDD_EQUAL_RANGES mode

* Add _MM_TRANSPOSE4_PS pseudo-macro. (rust-lang#106)

This adds a strange macro, which I've replaced with a function, because it
seems there are not many better alternatives.

Also adds a test, and `#[allow(non_snake_case)]` to `#[simd_test]`.

* Fix i586 tests

* Implement bitwise SSE ops & _mm_cmp*_ss  (rust-lang#103)

* Add _mm_{and,andnot,or,xor}_ps

* Add _mm_cmpeq_ss

* Add _mm_cmplt_ss

* Add _mm_cmple_ss

* Add _mm_cmpgt_ss

* Add _mm_cmpge_ss

* Add _mm_cmpneq_ss

* Add _mm_cmpnlt_ss

* Add _mm_cmpnle_ss

* Add _mm_cmpngt_ss

* Add _mm_cmpnge_ss

* Add _mm_cmpord_ss

* Add _mm_cmpunord_ss

* Fix _mm_{and,andnot,or,xor}_ps tests for i586

LLVM for i586 doesn't seem to generate `andps`, and instead generates 4
`and`s. Similar for the other operations.

* avx: _mm_maskload_pd

* avx: _mm_maskstore_pd

* avx: _mm256_maskload_ps

* avx: _mm256_maskstore_ps

* avx: _mm_maskload_ps, _mm_maskstore_ps

* avx: _mm256_movehdup_ps

* avx: _mm256_moveldup_ps
dlrobertson pushed a commit to dlrobertson/rust that referenced this issue Nov 29, 2018
…s_chapter

Fix broken links in macros chapter (issue rust-lang#82)
djtech-dev pushed a commit to djtech-dev/rust that referenced this issue Dec 9, 2021
A block without a parent doesn't have a next/previous. Return None in those cases.
This issue was closed.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants