[Bug]: error: ran out of registers during register allocation #2030
Comments
|
I have tested with stock LLVM/Clang in the following way: And it's able to compile the sample program without issue. This makes me thing is something with Android flavor of Clang. |
|
To clarify: there is no android flavor of Clang. We built it, but it's the upstream source. The reason for the behavior difference is that it's a different version of Clang, which does mean that this bug might be fixed in r28, which has a newer Clang than either r26 or r27. It's not likely that we'll have a backport for r26 at this point, as it doesn't sound like this is a regression from r25 (though we'll need to confirm that). r27 is a possibility though. |
|
Can you add |
|
Hello, output running with Here is a zip file with temp files: |
Thanks for the clarification. Our stack was previously being built with R18 (I know... a little bit old) and we only found this issue once we tried to move to R26. I have tested R22 & R23 and both seems to compile fine this piece of code. So definitely something introduced in R24. I dive deep into why boost lockfree queue triggers this behavior and it seems to be because the heavy use of templates to deduce compile/runtime size of the queue type. I tried to isolate an smaller program without use of boost library without success. Adding this context just in case is somehow helpful (I hope so). |
|
We'll see what we can do, but we do give priority to regressions from the previous release over bugs that have been broken for a long time (if they've been broken a long time and this is the first report, they probably aren't as wide spread). We're almost entirely dependent on upstream actually providing the fixes, but since it's working with LLVM 18 (and I think r27 is ever so slightly behind LLVM 18?), the odds are pretty good that there's already a fix we can cherry-pick. |
|
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. |
|
Using Either cherry-picking this patch to ndk or maybe adding this flag as default cc flags should be fine. |
|
Yeah so even with trunk compiler and with |
|
I hadn't read closely enough before (evidently I really needed that vacation) and missed that this was ASan related. @kellermanrivero, have you tried HWASan? ASan isn't actually supported for Android by upstream any more because there are so few reasons why it should be used over HWASan. See https://developer.android.com/ndk/guides/memory-debug for an overview of the tools available. ASan says "only as a last resort". HWASan was historically a pain to use, but as of U (which I know is extremely new) it's easier to use than ASan is. Clang shouldn't crash in any case and it'd be good to pick up the fix for this, but if you've got a better alternative you may not actually care :) |
|
@appujee great job! thanks for the dive deep here. It's extremely valuable. I feel I have somehow contributed to the project by reporting this error. @DanAlbert my team is moving away from a really old NDK r18 into latest one so I guess maybe ASAN was the recommended option for R18. I will try out HWASan and report the results back. Thanks both for the hard work here! |
r18 is old enough that I don't remember whether hwasan would work there or not, but I suspect you're right. Even if it did, I think you probably need an NDK that is aware of android U (which I think means r26+) to use the easy mode? |
|
Tentatively adding this for r27b so we remember to check, but due to the lack of upstream support for ASan, there may never be a fix for us to pick up. |
|
@DanAlbert I just realized that this issue specifically happens on Armv7 target so HWASan won't work since it only supports 64-bit architecture. |
|
Maybe. If the bug is present but asymptomatic on arm64, hwasan should still be able to catch it. If it's in arm32-specific code though, yeah, hwasan won't help you :( |
|
The reported bug in llvm-upstream has a reduced testcase, maybe that can give you some insight on a workaround in the mean time? llvm/llvm-project#98222 |
Description
Clang compiler for Arm (armv7) target fails to compile the following program:
./r27/bin/clang++ -I<path_to_boost_include_dir> -fsanitize=address -c -o sample.o sample.cpp
sample.cpp:
The output of the compiler is:
This compiler error is reproducible since R24. At least during my tests I found r23c seems to be able to compile this piece of code without major issues:
I'm unable to reproduce this bug with upstream LLVM so I'm not sure if this is specific of Android NDK.
Upstream bug
No response
Commit to cherry-pick
No response
Affected versions
r26, r27
Canary version
No response
Host OS
Linux, Mac
Host OS version
Amazon Linux 2, MacOS 14.5 (Sonoma)
Affected ABIs
armeabi-v7a
The text was updated successfully, but these errors were encountered: