stefson

@Flamefire are you able to confirm this on linux? I'm having trouble finding the commit that regressed this, downgrading up to 0.9.1 shows the same very choppy rendering if right...

disabling smart cursour does help as a workaround, but I've got the impression that the acceleration of the scrolling is now a bit over the top (:

I think this is the option I have to pass along to system highway, but I gave it a try anyway: ``` /usr/armv7a-unknown-linux-gnueabihf/usr/include/hwy/base.h:259:19: error: ‘__fp16’ does not name a type;...

@juippis are there any open bugs with logs for the reported lto issues with llvm/clang-15?

is it confirmed to work at runtime now?

I never noticed, but seems armv7a is affected as well: `clang -print-multiarch` gives `arm-linux-gnueabi` on armv7a-hardflat ``` clang -v clang version 13.0.1 Target: armv7a-unknown-linux-musleabihf Thread model: posix InstalledDir: /usr/lib/llvm/13/bin Selected...

oh, where did you pull it from? I just started merging 13.0.1 with the fix, will not be back around with the results before 24 hours, arm really is slow.

so, with the patch from this pullrequest applied to clang-13.0.1: `clang -print-multiarch` gives `arm-linux-musleabi` on armv7a-unknown-linux-musleabihf is this confirmation of the correct behavior? I'm uncertain, since there is no sign...

I don't know what the default behavior is :D but maybe you can expand the patch here: ``` return "arm-linux-androideabi"; if (TargetEnvironment == llvm::Triple::GNUEABIHF) return "arm-linux-gnueabihf"; - return "arm-linux-gnueabi"; +...

so, default behavior (without your patch) for armv7a+harfloat on glibc based system (armv7a-unknown-linux-gnueabihf) is: `clang-13 -print-multiarch` gives `arm-linux-gnueabihf` `clang-14 -print-multiarch` gives `arm-linux-gnueabihf` so yes, it seems that progress has been...