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

Generic vector reads read from the wrong place #301

Closed
pcwalton opened this issue Mar 31, 2011 · 1 comment
Closed

Generic vector reads read from the wrong place #301

pcwalton opened this issue Mar 31, 2011 · 1 comment

Comments

@pcwalton
Copy link
Contributor

Test case:

fn get[T](vec[T] v) -> T {
    ret v.(1);
}

fn main() {
    auto v = vec(1, 2, 3, 4, 5);
    log get(v);
}

Result:

[pwalton@fireferret ~/Source/rust/build] ./a.out
rt: ---
rt: 12ed:main:main:                       rust: 33554432 (0x2000000)

ret v.(0) works, so looks like we're miscalculating vec element size.

@pcwalton
Copy link
Contributor Author

Fixed by 7f3f66d.

oli-obk pushed a commit to oli-obk/rust that referenced this issue Sep 19, 2017
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
Fix ioctl types for non-x86 musl

This fixes up rust-lang#289 by changing the type for other platforms as well.
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
This was historically done as the contents of the `i686` module wouldn't
actually compile on i586 for various reasons. I believe I've tracked this down
to rust-lang#300 where LLVM refuses to compile a function using the `x86_mmx` type
without actually enabling the `mmx` feature (sort of reasonably so!). This
commit will now compile in both the `i586` and `i686` modules of this crate into
the `i586-unknown-linux-gnu` target, and the relevant functions now also enable
the `mmx` feature if they're using the `__m64` type.

I believe this is uncovering a more widespread problem where the `__m64` isn't
usable outside the context of `mmx`-enabled functions. The i686 and x86_64
targets have this feature enabled by default which is why it's worked there, but
they're not enabled for the i586 target. We'll probably want to consider this
when stabilizing!
antoyo added a commit to antoyo/rust that referenced this issue Oct 9, 2023
Add support for "returns_twice" function attribute
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
This is still incomplete, but hopefully it can be merged as an unstable
feature. I'll publish an RFC shortly.

This instruments the function body with assertion checks to see if users
are generating invalid values. This covers:
  - Union access
  - Raw pointer dereference
  - Transmute value
  - Field assignment of struct with invalid values
  - Aggregate assignment

Things not covered today should trigger ICE or a delayed verification
failure due to unsupported feature.

## Design

This change has two main design changes which are inside the new
`kani_compiler::kani_middle::transform` module:
1- Instance body should now be retrieved from the `BodyTransformation`
structure. This structure will run transformation passes on instance
bodies (i.e.: monomorphic instances) and cache the result.
2- Create a new transformation pass that instruments the body of a
function for every potential invalid value generation.
3- Create a body builder which contains all elements of a function body
and mutable functions to modify them accordingly.


Related to rust-lang#2998
Fixes rust-lang#301 

---------

Co-authored-by: Zyad Hassan <[email protected]>
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

No branches or pull requests

1 participant