| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
|
|
|
|
|
|
Pipe minor changes: diagnostics, flag support and comments
This PR:
- Add the exact syscall names to the blocking not supported diagnostic
- Added support for ``pipe2`` ``O_NONBLOCK``
- Fix minor comment error in ``tests/pass-dep/libc/libc-epoll-blocking.rs``
Fixes #3912
|
|
|
|
|
|
|
|
|
|
The shim syscall logic doesn't support ID 290, SYS_eventfd2.
|
|
Fix over synchronization of epoll
Fixes #3944.
The clock used by epoll is now per event generated, rather than by the `epoll's` ready_list.
The same epoll tests that existed before are unchanged and still pass. Also the `tokio` test case we had worked on last week still passes with this change.
This change does beg the question of how the epoll event states should change. Perhaps rather than expose public crate bool fields, so setters should be provided that include a clock parameter or an optional clock parameter. Also should all the epoll event possibilities have their clock sync tested the way these commit lay out testing. In this first go around, only the pipe's EPOLLIN is tested. The EPOLLOUT might deserve testing too, as would the eventfd. Any future source of epoll events would also fit into that category.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pthread mutex: better error in reentrant-locking-UB
Also test reentrant locking of PTHREAD_MUTEX_INITIALIZER
|
|
PTHREAD_MUTEX_INITIALIZER
|
|
|
|
|
|
|
|
|
|
|
|
This adds a VClock to the epoll implementation's ready_list
and has this VClock synced from the thread that updates
an event in the ready_list and then has the VClocks of any
threads being made runnable again, out of the calls to
epoll_wait, synced from it.
|
|
This test demonstrates the need to synchronize the clock
of the thread waking up from an epoll_wait from the thread
that issued the epoll awake event.
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
|
|
implements arc4random_buf shim for freebsd/solarish platforms.
close #3914
|
|
close #3914
|
|
|
|
- UnsafeCell: mention the term "data race", and reference the data race definition
- atomic: failing RMWs are just reads, reorder and reword docs
|
|
|
|
|
|
switch custom target JSON test to a less exotic target
We used to test an AVR target here, but while it is nice to test a 16bit target, it is also currently the case that rustc CI does not even check that libcore builds on a 16bit target -- and we don't want Miri to be in the game of maintaining that support. (See https://github.com/rust-lang/rust/issues/130818.)
So let's use a tier 2 target as the basis for testing a custom JSON target.
(FWIW, we also test wasm32-wasip2 which is tier 3, but I expect it will become tier 2 Soon-ish.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Check vtable projections for validity in miri
Currently, miri does not catch when we transmute `dyn Trait<Assoc = A>` to `dyn Trait<Assoc = B>`. This PR implements such a check, and fixes https://github.com/rust-lang/miri/issues/3905.
To do this, we modify `GlobalAlloc::VTable` to contain the *whole* list of `PolyExistentialPredicate`, and then modify `check_vtable_for_type` to validate the `PolyExistentialProjection`s of the vtable, along with the principal trait that was already being validated.
cc ``@RalfJung``
r? ``@lcnr`` or types
I also tweaked the diagnostics a bit.
---
**Open question:** We don't validate the auto traits. You can transmute `dyn Foo` into `dyn Foo + Send`. Should we check that? We currently have a test that *exercises* this as not being UB:
https://github.com/rust-lang/rust/blob/6c6d210089e4589afee37271862b9f88ba1d7755/src/tools/miri/tests/pass/dyn-upcast.rs#L14-L20
I'm not actually sure if we ever decided that's actually UB or not 🤔
We could perhaps still check that the underlying type of the object (i.e. the concrete type that was unsized) implements the auto traits, to catch UB like:
```rust
fn main() {
let x: &dyn Trait = &std::ptr::null_mut::<()>();
let _: &(dyn Trait + Send) = std::mem::transmute(x);
//~^ this vtable is not allocated for a type that is `Send`!
}
```
|
|
|
|
|
|
|
|
|
|
|
|
Correct outdated object size limit
The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.
The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.
try-job: i686-msvc
try-job: test-various
|
