Async++ concurrency framework for C++11
Intrusive collections for Rust
Generic Atomic<T> type for Rust
Rust port of Google's SwissTable hash map
Implementation of HashMap and HashSet for no_std environments
Implementation of CStr and CString for no_std environments
A markov chain generator written in C.
Lightweight printf-compatible format processing library
A vector with a fixed capacity. (Rust)
Some benchmarks of different languages
push eventrust-lang/stdarch
commit sha 9142a8a22d9ab4470167187e81aec503c2d70f60
Support ARM crypto extension on A32/T32 (#929)
push time in 11 hours
PR merged rust-lang/stdarch
ARM Crypto Extensions supports on aarch32 too. So we should allow this intrinsics on arm.
pr closed time in 11 hours
Pull request review commentrust-lang/hashbrown
Enable specialization with aHash
use hashbrown::HashMap; let mut map = HashMap::new(); map.insert(1, "one"); ```-+## Flags This crate has the following Cargo features: +- `inline-more`: Adds inline hints to most functions, improving run-time performance at the cost+ of compilation time. (enabled by default)+- `ahash`: Compiles with ahash as default hasher. (enabled by default)+- `std`: Enables use of features that depend on the standard library.
We only use serde to provide trait impls. It is up to the users of serde to decide whether they need std or not.
comment created time in 2 days
Pull request review commentrust-lang/stdarch
Support ARM crypto extension on A32/T32
use stdarch_test::assert_instr; /// AES single round encryption. #[inline] #[target_feature(enable = "crypto")]+#[cfg_attr(target_arch = "arm", target_feature(enable = "v8"))]
Is the v8 feature actually required here? Does it work without this feature?
comment created time in 2 days
pull request commentrust-lang/stdarch
Updated CONTRIBUTING.MD for new package name and environment variables
I would actually recommend using TARGET=<target> ci/run.sh to run the tests instead, it tends to work better in practice.
comment created time in 2 days
issue commentrust-lang/stdarch
Codegen tests fail on modern x86 CPUs due to `v` prefix
For the intrinsics we don't actually make any guarantees on what instructions the compiler will generate, so the tests are actually more picky than they should be. In general you shouldn't be using any -C target-cpu flags when running the tests except for ARM which needs -C target-feature=+neon.
comment created time in 2 days
pull request commentrust-lang/rust
Support custom allocators in `Box`
I would prefer keeping into_raw in Box<T, A>. Since there is only one regression and it is a) related to type inference and b) already fixed, I think we can go ahead with this change.
comment created time in 3 days
issue commentrust-lang/rust
Tracking issue for RFC 2360, `hint::bench_black_box`
Keep in mind that your code is a very artificial benchmark. In practice, the different components of a struct are likely to be in separate registers. In that case it is usually faster to store everything to memory than to do bit shuffling to fit everything in one register.
comment created time in 3 days
pull request commentrust-lang/hashbrown
Enable specialization with aHash
I think the current behavior is fine. Using constant keys should also improve performance a bit.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Enable specialization with aHash
use hashbrown::HashMap; let mut map = HashMap::new(); map.insert(1, "one"); ```-+## Flags This crate has the following Cargo features: +- `inline-more`: Adds inline hints to most functions, improving run-time performance at the cost+ of compilation time. (enabled by default)+- `ahash`: Compiles with ahash as default hasher. (enabled by default)+- `std`: Enables use of features that depend on the standard library.+ If `ahash` is used this includes using random keys to provide DOS resistance. (disabled by default)+- `ahash-compile-time-rng`: This is an alternative to `std` which still allows for some degree of DOS-resistance.+ However, it can result in issues for certain platforms.
This is overly vague. Just say that the main downside is that builds are no longer reproducible.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Enable specialization with aHash
where #[cfg_attr(feature = "inline-more", inline)] pub(crate) fn make_hash<K: Hash + ?Sized>(hash_builder: &impl BuildHasher, val: &K) -> u64 {- let mut state = hash_builder.build_hasher();- val.hash(&mut state);- state.finish()+ #[cfg(feature = "ahash")]
A comment explaining what is going on here would be helpful (specialization to improve performance).
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Enable specialization with aHash
use hashbrown::HashMap; let mut map = HashMap::new(); map.insert(1, "one"); ```-+## Flags This crate has the following Cargo features: +- `inline-more`: Adds inline hints to most functions, improving run-time performance at the cost+ of compilation time. (enabled by default)+- `ahash`: Compiles with ahash as default hasher. (enabled by default)+- `std`: Enables use of features that depend on the standard library.
Rather than a std flag, I think we should have a ahash-randomize-key flag which is documented to depend on std.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
impl<K: Debug, V: Debug> Debug for RustcEntry<'_, K, V> { pub struct RustcOccupiedEntry<'a, K, V> { key: Option<K>, elem: Bucket<(K, V)>,- table: &'a mut RawTable<(K, V)>,+ table: &'a mut RawTable<(K, V), Global>,
We'll have to find a way to make this work with any allocator when we add allocator support to the std HashMap.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
impl<T> RawTable<T> { items: 0, growth_left: 0, marker: PhantomData,+ alloc: Global,+ }+ }+}++impl<T, A: AllocRef + Clone> RawTable<T, A> {+ /// Creates a new empty hash table without allocating any memory, using the+ /// given allocator.+ ///+ /// In effect this returns a table with exactly 1 bucket. However we can+ /// leave the data pointer dangling since that bucket is never written to+ /// due to our load factor forcing us to always have at least 1 free bucket.+ #[cfg_attr(feature = "inline-more", inline)]+ pub fn new_in(alloc: A) -> Self {
Also this should be a const fn.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
impl<T> ExactSizeIterator for RawIter<T> {} impl<T> FusedIterator for RawIter<T> {} /// Iterator which consumes a table and returns elements.-pub struct RawIntoIter<T> {+pub struct RawIntoIter<T, A: AllocRef + Clone> { iter: RawIter<T>, alloc: Option<(NonNull<u8>, Layout)>,
Maybe rename this to allocation to avoid confusion.
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
impl<T> RawTable<T> { items: 0, growth_left: 0, marker: PhantomData,+ alloc: Global,+ }+ }+}++impl<T, A: AllocRef + Clone> RawTable<T, A> {+ /// Creates a new empty hash table without allocating any memory, using the+ /// given allocator.+ ///+ /// In effect this returns a table with exactly 1 bucket. However we can+ /// leave the data pointer dangling since that bucket is never written to+ /// due to our load factor forcing us to always have at least 1 free bucket.+ #[cfg_attr(feature = "inline-more", inline)]+ pub fn new_in(alloc: A) -> Self {
Could you change new to call new_in to avoid the code duplication?
comment created time in 3 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
impl<T> Bucket<T> { } /// A raw hash table with an unsafe API.-pub struct RawTable<T> {+pub struct RawTable<T, A: AllocRef + Clone> {
I would prefer if we only had bounds on impl blocks rather than on the structs themselves.
comment created time in 3 days
push eventrust-lang/stdarch
commit sha 9b9a7d572cae9bd74b9cee4e184fa35cdbc8b029
Avx512f (#927)
push time in 4 days
PR merged rust-lang/stdarch
roundscale_round: ps,pd; roundscale: ps,pd scalef_round: ps,pd; scalef: ps,pd reduce_mul: epi64, reduce_max: epi64,epu64, reduce_min: epi64,epu64, reduce_and: epi64, reduce_or: epi64 fixupimm_round: ps,pd; fixupimm: ps,pd ternarylogic: epi32, epi64 int2mask, mask2int, stream: ps,pd,si512 mask_set1: epi32,epi64, maskz_set1: epi32,epi64 test_epi32_mask, test_epi64_mask, testn_epi32_mask, testn_epi64_mask mask_mov: epi32,epi64,ps,pd; maskz_mov: epi32,epi64,ps,pd mm_mask_add: ss,sd; mm_mask_sub: ss,sd; mm_mask_mul: ss,sd; mm_mask_div: ss,sd; add_round: ss,sd; sub_round: ss,sd; mul_round: ss,sd; div_round: ss,sd; mask_sqrt: ss,sd; sqrt_round: ss,sd; rsqrt14: ss,sd; rcp14: ss,sd; getexp: ss,sd; getexp_round: ss,sd; getmant: ss,sd; getmant_round: ss,sd; roundscale: ss,sd; roundscale_round: ss,sd; scalef: ss,sd; scalef_round: ss,sd; mask_move: ss,sd; mask_fmadd: ss,sd; mask_round: ss,sd;
pr closed time in 4 days
Pull request review commentrust-lang/stdarch
-#![feature(stdsimd, avx512_target_feature)]
Why did you delete this file?
comment created time in 4 days
Pull request review commentrust-lang/stdarch
pub unsafe fn _mm512_kmov(a: __mmask16) -> __mmask16 { transmute(r) } +/// Converts integer mask into bitmask, storing the result in dst.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_int2mask&expand=3189)+#[inline]+#[target_feature(enable = "avx512f")] // generate normal and code instead of kmovw+pub unsafe fn _mm512_int2mask(mask: i32) -> __mmask16 {+ assert!(mask >= 0);
Remove this assert, we should silently truncate in this case.
comment created time in 4 days
Pull request review commentrust-lang/stdarch
pub unsafe fn _mm512_maskz_ternarylogic_epi32( transmute(simd_select_bitmask(k, ternarylogic, zero)) } +/// Bitwise ternary logic that provides the capability to implement any three-operand binary function; the specific binary function is specified by value in imm8. For each bit in each packed 64-bit integer, the corresponding bit from a, b, and c are used to form a 3 bit index into imm8, and the value at that bit in imm8 is written to the corresponding bit in dst.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_ternarylogic_epi64&expand=5876)+#[inline]+#[target_feature(enable = "avx512f")]+#[cfg_attr(test, assert_instr(vpternlogq, imm8 = 114))]+#[rustc_args_required_const(3)]+pub unsafe fn _mm512_ternarylogic_epi64(a: __m512i, b: __m512i, c: __m512i, imm8: i32) -> __m512i {+ macro_rules! call {+ ($imm8:expr) => {+ vpternlogq(a.as_i64x8(), b.as_i64x8(), c.as_i64x8(), $imm8)+ };+ }+ let r = constify_imm8_sae!(imm8, call);+ transmute(r)+}++/// Bitwise ternary logic that provides the capability to implement any three-operand binary function; the specific binary function is specified by value in imm8. For each bit in each packed 64-bit integer, the corresponding bit from src, a, and b are used to form a 3 bit index into imm8, and the value at that bit in imm8 is written to the corresponding bit in dst using writemask k at 64-bit granularity (64-bit elements are copied from src when the corresponding mask bit is not set).+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_mask_ternarylogic_epi64&expand=5874)+#[inline]+#[target_feature(enable = "avx512f")]+#[cfg_attr(test, assert_instr(vpternlogq, imm8 = 114))]+#[rustc_args_required_const(4)]+pub unsafe fn _mm512_mask_ternarylogic_epi64(+ src: __m512i,+ k: __mmask8,+ a: __m512i,+ b: __m512i,+ imm8: i32,+) -> __m512i {+ macro_rules! call {+ ($imm8:expr) => {+ vpternlogq(src.as_i64x8(), a.as_i64x8(), b.as_i64x8(), $imm8)+ };+ }+ let ternarylogic = constify_imm8_sae!(imm8, call);+ transmute(simd_select_bitmask(k, ternarylogic, src.as_i64x8()))+}++/// Bitwise ternary logic that provides the capability to implement any three-operand binary function; the specific binary function is specified by value in imm8. For each bit in each packed 64-bit integer, the corresponding bit from a, b, and c are used to form a 3 bit index into imm8, and the value at that bit in imm8 is written to the corresponding bit in dst using zeromask k at 64-bit granularity (64-bit elements are zeroed out when the corresponding mask bit is not set).+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_maskz_ternarylogic_epi64&expand=5875)+#[inline]+#[target_feature(enable = "avx512f")]+#[cfg_attr(test, assert_instr(vpternlogq, imm8 = 114))]+#[rustc_args_required_const(4)]+pub unsafe fn _mm512_maskz_ternarylogic_epi64(+ k: __mmask8,+ a: __m512i,+ b: __m512i,+ c: __m512i,+ imm8: i32,+) -> __m512i {+ macro_rules! call {+ ($imm8:expr) => {+ vpternlogq(a.as_i64x8(), b.as_i64x8(), c.as_i64x8(), $imm8)+ };+ }+ let ternarylogic = constify_imm8_sae!(imm8, call);+ let zero = _mm512_setzero_si512().as_i64x8();+ transmute(simd_select_bitmask(k, ternarylogic, zero))+}++/// Normalize the mantissas of packed single-precision (32-bit) floating-point elements in a, and store the results in dst. This intrinsic essentially calculates ±(2^k)*|x.significand|, where k depends on the interval range defined by interv and the sign depends on sc and the source sign.
Accidentally duplicated comment?
comment created time in 4 days
issue commentrust-lang/rust
Tracking issue for RFC 2360, `hint::bench_black_box`
I'd just use the fallback path if it doesn't fit in a usize exactly.
comment created time in 4 days
issue commentrust-lang/rust
Built-in u128 performance compared to extprim crate
You need to update the compiler-builtins version in Cargo.lock of rust-lang/rust.
comment created time in 4 days
issue commentrust-lang/rust
Tracking issue for RFC 2360, `hint::bench_black_box`
let mut int_x: usize = mem::transmute_copy(&man_x);
This line is unsound if x is smaller than usize, see the documentation for transmute_copy.
comment created time in 4 days
pull request commentrust-lang/rust
Stabilize slice::strip_prefix and slice::strip_suffix
@rfcbot fcp merge
This API seems fine for now, but https://github.com/rust-lang/rfcs/pull/2500 plans to generalize them to take a Pattern as an argument instead.
comment created time in 5 days
issue commentrust-lang/rust
Built-in u128 performance compared to extprim crate
You can try dumping the disassembly of the final executable with objdump -d <file> or llvm-objdump -d <file>. Search for __divti3 in the output.
comment created time in 5 days
push eventrust-lang/hashbrown
Deployment Bot (from Travis CI)
commit sha 4ef789f7c9e79db13a6656da7c57b2345ed11f74
Deploy rust-lang/hashbrown to github.com/rust-lang/hashbrown.git:gh-pages
push time in 5 days
pull request commentrust-lang/hashbrown
Remove the need for unwrap when using ProbeSeq
@bors r+
comment created time in 5 days
issue commentrust-lang/rust
Tracking issue for #[ffi_returns_twice]
I am very hesitant to do so since it would stabilize a horrible hack that C uses for two functions: vfork and setjmp. In particular:
- This basically works by disabling a bunch of optimizations in LLVM, but it would likely require additional work in rustc for MIR optimizations.
- Functions that return twice are a hack, you can't even implement such functions in C: they must be written in assembly.
- If you really want to use
vforkthen you should use a C or asm wrapper that hides the "returns twice" hack and provides a safe callback interface that allows you to run a function in the child process.
comment created time in 5 days
push eventrust-lang/stdarch
commit sha 1542c856a6f29f1f4e96eed59a832f7143ff68d4
Fix URLs (#928)
push time in 6 days
pull request commentrust-lang/rust
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors
GitHub Actions has encountered an internal error when running your job.
@bors retry
comment created time in 6 days
Pull request review commentrust-lang/hashbrown
Remove the need for unwrap when using ProbeSeq
fn h2(hash: u64) -> u8 { /// Proof that the probe will visit every group in the table: /// <https://fgiesen.wordpress.com/2015/02/22/triangular-numbers-mod-2n/> struct ProbeSeq {- bucket_mask: usize, pos: usize, stride: usize, } -impl Iterator for ProbeSeq {- type Item = usize;-- #[inline]- fn next(&mut self) -> Option<usize> {+impl ProbeSeq {+ fn move_next(&mut self, bucket_mask: usize) {
Also this method needs #[inline].
comment created time in 6 days
Pull request review commentrust-lang/hashbrown
Remove the need for unwrap when using ProbeSeq
fn h2(hash: u64) -> u8 { /// Proof that the probe will visit every group in the table: /// <https://fgiesen.wordpress.com/2015/02/22/triangular-numbers-mod-2n/> struct ProbeSeq {- bucket_mask: usize, pos: usize, stride: usize, } -impl Iterator for ProbeSeq {- type Item = usize;-- #[inline]- fn next(&mut self) -> Option<usize> {+impl ProbeSeq {+ fn move_next(&mut self, bucket_mask: usize) {
Why did you change this to pass the bucket mask as an argument?
comment created time in 6 days
Pull request review commentrust-lang/hashbrown
Remove the need for unwrap when using ProbeSeq
impl<T> RawTable<T> { /// There must be at least 1 empty bucket in the table. #[cfg_attr(feature = "inline-more", inline)] fn find_insert_slot(&self, hash: u64) -> usize {- for pos in self.probe_seq(hash) {+ let mut probe_seq = self.probe_seq(hash);+ loop {+ let pos = probe_seq.pos;
Just use probe_seq.pos directly in the code below.
comment created time in 6 days
pull request commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
You need a second #[allow] for line 47.
comment created time in 7 days
Pull request review commentrust-lang/hashbrown
Parametrize RawTable, HashSet and HashMap over an allocator
mod inner { pub use crate::alloc::alloc::{AllocRef, Global}; use core::ptr::NonNull; + #[allow(clippy::map-err-ignore)]
#[allow(clippy::map_err_ignore)]
comment created time in 7 days
pull request commentrust-lang/rust
feat: Update hashbrown to instantiate less llvm IR
@bors try @rust-timer queue
comment created time in 8 days
push eventAmanieu/parking_lot
commit sha bb0bfb384bb86c27c6db59ea6987e3410be108a4
Update to cfg-if 1.0
commit sha ab3718f6b5b57e9059ef15e1aa880e86aa0c2ff5
Merge pull request #253 from mbrubeck/deps Update to cfg-if 1.0
push time in 8 days
pull request commentrust-lang/rust
Stabilize slice_partition_at_index
Thanks!
@bors r+
comment created time in 8 days
pull request commentrust-lang/hashbrown
Enable specialization with aHash
CI is failing.
comment created time in 8 days
issue commentrust-lang/rust
Tracking Issue for inline assembly (`asm!`)
Basically intel syntax is broken on LLVM < 10.0.1. The workaround (which we use in libstd) is to use the att_syntax option and use AT&T syntax.
comment created time in 9 days
issue closedAmanieu/intrusive-rs
Is this pattern for removing an item from a list safe?
I have a use case where I want to iterate through a linked list and remove the "best" item (by whatever metric). So it involves testing each item, maintaining a reference to the best one found so far, then afterward removing the best item from the list.
This is roughly the code I want to use. It works, but results in the warning https://github.com/rust-lang/rust/issues/59159, which will soon turn into a hard error, that list is being mutably borrowed while reference is already immutably borrowing list.
fn pluck_best_item(list: &mut LinkedList<LinkAdapter>, prefix: &str) -> Option<Rc<Thing>> {
let mut best_so_far = None;
for thing in list.iter() {
if is_better_candidate_for_removal(thing, &best_so_far) {
best_so_far = Some(thing);
}
}
if let Some(reference) = best_so_far {
let mut cursor = unsafe { list.cursor_mut_from_ptr(reference) };
return cursor.remove();
}
None
}
I found that casting the reference to a *const drops the immutable borrow and makes the borrow checker happy, like so:
if let Some(reference) = best_so_far {
let ptr = reference as *const Thing;
let mut cursor = unsafe { list.cursor_mut_from_ptr(ptr) };
return cursor.remove();
}
Is this pattern safe at all? Not just casting the reference to a pointer, but the whole thing: maintaining a reference that was borrowed immutably to create a mutable cursor in order to remove the item. If it's unsafe, is there a better way to do what I'm trying to?
closed time in 9 days
TooManyBees
pull request commentrust-lang/rust
Avoid SeqCst or static mut in mach_timebase_info and QueryPerformanceFrequency caches
@bors retry
comment created time in 9 days
issue commentAmanieu/intrusive-rs
Is this pattern for removing an item from a list safe?
You may have to perform the cast when assigning best_so_far: best_so_far = Some(thing as *const _).
It is safe since even mutable cursors only expose an immutable reference to elements in the collection.
comment created time in 9 days
push eventrust-lang/stdarch
commit sha 7b927565def66c2b5b2e268eebb3a547d90425ab
Avx512f (#921)
push time in 10 days
PR merged rust-lang/stdarch
alignr: epi32,epi64 zextps128_ps512,zextps256_ps512,zextpd128_pd512,zextpd256_pd512,zextsi128_si512,zextsi256_si512 undefined: epi32, (); set_zero: epi32, () set_epi8, set_epi16, set1_epi8, set1_epi16 set4: epi32,epi64,ps,pd; setr4: epi32,epi64,ps,pd cvtepi8_epi32, cvtepi8_epi64, cvtepu8_epi32, cvtepu8_epi64 cvtepi16_epi32, cvtepi16_epi64, cvtepu16_epi32, cvtepu16_epi64 cvtepi32_epi64, cvtepu32_epi64, cvtepi32_ps, cvtepi32_pd cvtepu32_ps, cvtepu32_pd, cvtepi32lo_pd, cvtepu32lo_pd cvtepi32_epi16, cvtepi32_epi8, cvtepi64_epi32, cvtepi64_epi16, cvtepi64_epi8 cvtsepi32_epi16, cvtsepi32_epi8 cvtsepi64_epi32, cvtsepi64_epi16, cvtsepi64_epi8 cvtusepi32_epi16, cvtusepi32_epi8, cvtusepi64_epi32, cvtusepi64_epi16, cvtusepi64_epi8 cvtpd_ps, cvt_roundpd_ps cvtpd_pslo, cvtpslo_pd cvt_roundpd_epi32, cvt_roundpd_epu32 cvt_roundepi32_ps, cvt_roundepu32_ps cvt_roundps_ph, cvtps_ph cvt_roundph_ps, cvtph_ps reduce_add: epi32,ps,pd reduce_mul: epi32,ps,pd reduce_max: epi32,epu32,ps,pd reduce_min: epi32,epu32,ps,pd reduce_and: epi32 loadu: epi32,epi64,si512; storeu: epi32,epi64,si512 load: epi32,epi64,si512,ps,pd; store: epi32,epi64,si512,ps,pd extractf32x4_ps, extractf64x4_pd, extracti32x4_epi32, extracti64x4_epi64 reduce_or: epi32 compress: epi32,epi64,ps,pd expand: epi32,epi64,ps,pd
pr closed time in 10 days
pull request commentrust-lang/rust
fix __rust_alloc_error_handler comment
@bors rollup
comment created time in 10 days
pull request commentrust-lang/rust
fix __rust_alloc_error_handler comment
@bors r+
comment created time in 10 days
Pull request review commentrust-lang/rust
fix __rust_alloc_error_handler comment
pub(crate) unsafe fn box_free<T: ?Sized>(ptr: Unique<T>) { } } +// # Allocation error handler++extern "Rust" {+ // This is the magic symbol to call the global alloc error handler. rustc generates+ // it to call `__rg_oom` if there is a `#[global_allocator]`, or uses the+ // default implementations below (`__rdl_oom`) otherwise.+ #[rustc_allocator_nounwind]
I think it's fine to leave the attribute for now.
comment created time in 10 days
pull request commentrust-lang/rust
Avoid SeqCst or static mut in mach_timebase_info and QueryPerformanceFrequency caches
At the moment all platforms that mac and windows support will support AtomicU64, so I think it's fine to depend on it.
@bors r+
comment created time in 10 days
issue commentrust-lang/rust
Tracking isuse for `handle_alloc_error` defaulting to panic (for no_std + liballoc)
Ah actually it seems that the GlobalAlloc trait doesn't allow unwinding:
It's undefined behavior if global allocators unwind. This restriction may be lifted in the future, but currently a panic from any of these functions may lead to memory unsafety.
Looking through some old threads, it seems that allowing allocators to unwind does indeed cause some code size regressions: #42808
From https://github.com/rust-lang/rust/issues/42808#issuecomment-323839473 it seems that most of the code size regression comes from unwinding edges from dealloc so we could only keep dealloc as nounwind while allowing the other allocator methods to unwind, including the OOM handler.
comment created time in 10 days
issue commentrust-lang/rust
Tracking isuse for `handle_alloc_error` defaulting to panic (for no_std + liballoc)
I don't think we gain much from eliminating the OOM unwinding edges considering the allocator itself can already panic.
I would like std to eventually also transition to panicking instead of aborting on OOM since it gives applications a chance to handle OOMs and return an error. This is needed for libraries such as cURL that use Rust components and need to be robust when encountering OOM situations.
comment created time in 10 days
Pull request review commentrust-lang/rust
Stabilize slice_partition_at_index
impl<T> [T] { sort::quicksort(self, |a, b| f(a).lt(&f(b))); } + /// Reorder the slice such that the element at `index` is at its final sorted position.+ ///+ /// This function has been obsoleted by [`select_nth_unstable`], and will be removed in+ /// a later release.+ #[unstable(feature = "slice_partition_at_index", issue = "55300")]
Could you mark these as deprecated with a suggestion to use select_nth_unstable instead?
comment created time in 10 days
push eventrust-lang/compiler-builtins
commit sha e9688c68a5dd3ebe98f27386c6459afaf87c0468
Remove unneeded code from asymmetric.rs Rebenchmarking this showed that perf changed for the worse only on really low end CPUs
commit sha 1d15e4e5043edcde12b8a2412f084c387f07ecc6
Construct signed division functions differently
commit sha d65785b8eebf0ee4b7af13e5120544481b4b9d37
Hide macros and functions These macros and functions are only in the public interface for testing purposes or because of `#[macro_export]` pollution
commit sha 3a769f6332cf6c8ad7298d09866f87efaf609417
Merge pull request #380 from AaronKutch/division-tweaks
push time in 10 days
PR merged rust-lang/compiler-builtins
This slims down asymmetric.rs, removes the old style signed division macro code, and constructs signed divisions independent of the specialized_div_rem module. I figured out that when this is done, LLVM autoinlines just how I want it (except that the code gen for RISCV is still horrendous, I guess my leading_zeros changes still have not made it into nightly). The fact that I don't have to manage the signed divisions in the specialized_div_rem module will make it much easier to convert some macros to generics later. In another PR, I will fix problems I have with the division testing code and improve the edge cases that it covers.
pr closed time in 10 days
pull request commentrust-lang/rust
Remove special case for x86_64-*-windows-gnu in panic_abort
Are you sure this is actually correct? I believe this personality function is still called for SEH exceptions such as segfaults, in which case we want to return 1 to indicate that we do not handle such exceptions.
comment created time in 10 days
issue commentrust-lang/rust
Make `handle_alloc_error` default to panic (for no_std + liballoc)
@rust-lang/libs We've already had an FCP for this, but that was before it was implemented. Do we need another FCP for the implementation or can we stabilize it right away?
comment created time in 12 days
issue commenttkaitchuck/aHash
Please reconsider the strategy in `RandomState` for getting a hashing key
LGTM
comment created time in 13 days
issue commentrust-lang/hashbrown
This is happening because old versions of ahash have been yanked. You should update your hashbrown dependency to the latest version which is 0.9.1.
comment created time in 13 days
issue commentAmanieu/parking_lot
I'm happy to add sanitizer support under a feature flag.
comment created time in 13 days
pull request commentrust-lang/rust
Support custom allocators in `Box`
@craterbot check
comment created time in 13 days
pull request commentrust-lang/rust
Add in-place optimization for array map
r? @scottmcm
comment created time in 13 days
pull request commentrust-lang/stdarch
Stabilize WebAssembly atomic intrinsics
Is there a tracking issue for these? It needs an FCP before it can be stabilized. (rfcbot isn't enabled on this repo).
comment created time in 13 days
pull request commentrust-lang/rust
Support custom allocators in `Box`
@bors try
comment created time in 13 days
pull request commentrust-lang/rust
Add in-place optimization for array map
Have you verified that this in fact produces better assembly code in practice?
comment created time in 14 days
issue commentrust-lang/stdsimd
Currrently we tie the stabilization of target_feature features with the implementation of the relevant intrinsics in stdarch (The AVX512 intrinsics are still incomplete). However with stdsimd I think we should separate these now that we have stdsimd.
comment created time in 14 days
pull request commentrust-lang/rust
Add PartialEq impls for Vec <-> slice
@bors retry
comment created time in 14 days
push eventrust-lang/stdarch
commit sha a5db4eaf65b961a6e0ddd9397637700b4efca077
replace some unions by transmute and make the rest repr(C) (#925)
push time in 14 days
PR merged rust-lang/stdarch
Turns out the untagged_unions feature already was not needed.
Fixes https://github.com/rust-lang/stdarch/issues/924
pr closed time in 14 days
issue closedrust-lang/stdarch
Remove untagged_unions feature
Once https://github.com/rust-lang/rust/pull/77547 lands, I think the untagged_unions feature can be removed from stdarch. I do not know what the usual process for this is, does stdarch use bootstrap flags like everything else?
I also noticed stdarch tests use unions to transmute things. Is there any particular reason why the tests do not use transmute? Note in particular that stdarch is using unions incorrectly here; without repr(C), there is no guarantee that the union fields all start at the same offset.
closed time in 14 days
RalfJung
Pull request review commentrust-lang/stdarch
pub unsafe fn _mm512_setr_epi64( transmute(r) } +/// Set packed 64-bit integers in dst with the repeated 4 element sequence.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_set4_epi64&expand=4983)+#[inline]+#[target_feature(enable = "avx512f")]+pub unsafe fn _mm512_set4_epi64(d: i64, c: i64, b: i64, a: i64) -> __m512i {+ _mm512_set_epi64(d, c, b, a, d, c, b, a)+}++/// Set packed 64-bit integers in dst with the repeated 4 element sequence in reverse order.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_setr4_epi64&expand=5010)+#[inline]+#[target_feature(enable = "avx512f")]+pub unsafe fn _mm512_setr4_epi64(d: i64, c: i64, b: i64, a: i64) -> __m512i {+ _mm512_set_epi64(a, b, c, d, a, b, c, d)+}
Those too.
comment created time in 15 days
Pull request review commentrust-lang/stdarch
pub unsafe fn _mm512_setr_epi64( transmute(r) } +/// Set packed 64-bit integers in dst with the repeated 4 element sequence.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_set4_epi64&expand=4983)+#[inline]+#[target_feature(enable = "avx512f")]+pub unsafe fn _mm512_set4_epi64(d: i64, c: i64, b: i64, a: i64) -> __m512i {+ _mm512_set_epi64(d, c, b, a, d, c, b, a)+}++/// Set packed 64-bit integers in dst with the repeated 4 element sequence in reverse order.+///+/// [Intel's documentation](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=512_setr4_epi64&expand=5010)+#[inline]+#[target_feature(enable = "avx512f")]+pub unsafe fn _mm512_setr4_epi64(d: i64, c: i64, b: i64, a: i64) -> __m512i {+ _mm512_set_epi64(a, b, c, d, a, b, c, d)+}
All the set intrinsics should be added to the whitelist and moved to x86.
comment created time in 15 days
pull request commentrust-lang/rust
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors
@bors r+
comment created time in 15 days
issue commentrust-lang/stdarch
Remove untagged_unions feature
It's fine for stdarch to use the bootstrap flag since it is built as a submodule of core. This will be ignored in CI which builds it as a separate crate.
Regarding the tests I don't think there was any intentional reason to use unions. I wouldn't mind a PR changing them to use transmute or repr(C) unions instead.
comment created time in 15 days
pull request commentrust-lang/rust
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors
@bors r+
comment created time in 16 days
pull request commentrust-lang/hashbrown
Reduce the amount of llvm IR instantiated
The changes mostly look good. However they are quite invasive so I would feel more comfortable if we could test the impact of this change in compilation performance.
Could you try creating a PR in rust-lang/rust which switches libstd to use your branch of hashbrown so that we can do a perf run?
comment created time in 16 days
pull request commentrust-lang/rust
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors
@bors r+
comment created time in 16 days