appujee
appujee
https://r.android.com/3218272 reverts the above mentioned patch.
Landed in upstream.
clang-18.0.0(r510928) doesn't crash but 18.0.1(r522817) does.
Simpler command line to repro with the provided sample.ii file. ``` $CC -cc1 -triple armv7-unknown-linux-android21 -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name sample.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -ffp-contract=on...
Using `-mllvm -asan-use-stack-safety=1` fixes the error. I feel the problem is still latent in llvm but after https://github.com/llvm/llvm-project/pull/77210 the error went away. Either cherry-picking this patch to ndk or maybe...
Yeah so even with trunk compiler and with `-mllvm -asan-use-stack-safety=0` we get this error. ~The error only occurs for Android targets though~. https://godbolt.org/z/5ocv7Wsa9
The reported bug in llvm-upstream has a reduced testcase, maybe that can give you some insight on a workaround in the mean time? https://github.com/llvm/llvm-project/issues/98222
For llvm, we should have a way to differentiate fast unaligned access support for both scalars and vectors. The current -mno-strict-align is confusing and resulting in bug like this. See...
> Zicclsm was defined is a mandatory extension in the [RVA20 profile](https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#512-rva20u64-mandatory-extensions) and is explicitly specified as indicating support for misaligned load/store for both scalar and vector memory operations. Makes...
> Does hwprobe report that unaligned accesses are fast on this CPU? @sh1boot can you provide the info?