Folkert de Vries

Can we split `any_zlib` into "supports the zlib api" and "uses a C implementation" flags? - `any_zlib_api`: any backend that is able to provide something consistent with the full zlib...

Hmm well I made the current setup work, and the split would probably not really help that much.

Not sure, how would I test that? I know that the plan is to eventually remove `repr(simd)`, that's why I left it out above.

based on https://godbolt.org/z/W4Y1rrfc4 ```rust #![feature(repr_simd)] #[derive(Clone, Copy)] #[repr(simd, packed(1))] struct __m128d_u([f64; 2]); #[unsafe(no_mangle)] extern "C" fn id(x: &__m128d_u) -> __m128d_u { *x } ``` It does not, In fact, it...

I checked with Jubilee and `packed` getting ignored is deliberate. So in effect I guess it's not possible today to have a type that is passed like a vector, but...

This has now been reviewed by several people from the rust embedded community and from Arm, so I think this is ready for T-lang to take a look. @rustbot label...

Ah, yeah, I had another thought that we may want to generate number-of-cores files instead of 3k+ separate files.

In https://github.com/rust-lang/stdarch/pull/1856, CI time for `aarch64-unknown-linux-gnu` is down from 28 minutes to 8 minutes. We could still go faster, but at that point it is no longer the longest-running CI...

Hmm, could this be some sort of overflow bug, given the large inputs? Otherwise I'd need some sort of specific sequence of inputs to zlib to say anything useful.

Assuming - the problem here would be in decompression - gixoxide only makes one `Decompress` and reuses it I'd just need the sequence of inputs to `decompress` here https://github.com/GitoxideLabs/gitoxide/blob/df393f37bb03955eff3ad52c27440393737fb334/gix-features/src/zlib/mod.rs#L47 Something...