On 2023/03/03 06:49, Bjorn Ketelaars wrote: > On Fri 03/03/2023 01:55, Theo Buehler wrote: > > zstd is broken on sparc64 due to unaligned accesses resulting in bus > > errors. Since __GNUC__ is defined and MEM_FORCE_MEMORY_ACCESS isn't > > defined, it defaults to 1, and we run into these: > > > > https://github.com/facebook/zstd/blob/1be95291a89160be121c987c2e385331a65a4a0e/lib/common/mem.h#L192-L199 > > > > One simple fix is to define MEM_FORCE_MEMORY_ACCESS to 0 via CPPFLAGS. > > This forces all platforms to use memcpy, which may or may not result in > > some slowdown. We can consider more elaborate platform-specific fixes if > > that is desired, but then I need instructions. > > > > With this diff, the cmake test for zstd doesn't abort with a bus error, > > which allows me to build qt6/qtbase on sparc64, and in turn we should > > get a sizable chunk of the tree back to building.
So it's from this commit https://github.com/facebook/zstd/commit/a78c91ae59b9487fc32224b67c4a854dc3720367 > I did some light benchmarking using your patch and first impression, > i.e. looking at the numbers, is that there is no slow dowm. I did *not* > perform statistical analysis to underpin this observation. > > That said I have a slight preference for making this change platform > specific, and tested https://pbot.rmdir.de/9-6H2Qy6ah89TpUnMYCzeg. If we're taking that approach, can we have some test (e.g. in post-build) so that zstd build fails on an arch that requires this so we can keep the list up to date more easily? Though I think my preference for now would be to either use the MEM_FORCE_MEMORY_ACCESS=0 hammer for all archs, or patch to backout that upstream commit, and report upstream to see what they want to do..
