User Details
- User Since
- Jan 30 2018, 2:05 AM (231 w, 12 h)
May 31 2022
Any news on this?
May 25 2022
I have created a new revision which works fine for me on mips64el, see: https://reviews.llvm.org/D126418
May 19 2022
May 18 2022
May 16 2022
May 15 2022
Could someone land this for me? Thanks!
May 14 2022
Maybe after you land the sparc fix.
May 13 2022
May 12 2022
This change unfortunately broke the build on Linux/sparc64.
Feb 11 2022
Jan 31 2022
Issue has been fixed in GCC, we can drop this change now.
GCC has now been updated to use the V8+ baselone on sparc64 in 32-bit mode, so we can drop this patch altogether.
Jan 28 2022
Any news on this?
Jan 24 2022
OK, so gcc is going to enable V8plus for 32-bit V9 as well. So we can just drop this patch ;-).
Thanks, that's actually a workaround I have also used in the past!
Ah, I actually ran into this very problem! Thanks for fixing this.
Jan 23 2022
gcc might be fixed in the future to enable 64-bit atomic operations with -m32 -mcpu=v9, see [1].
Jan 22 2022
FWIW, gcc actually behaves differently on Solaris:
Use "-mcpu=ultrasparc3" instead of "-mv8plus" as the latter will break the stage1 testsuite with clang.
OK, it seems we can use -mcpu=ultrasparc3 instead which is also understood by clang:
Hmm, it looks like the testsuite is stumbling over this change as it actually tries to run clang in g++-mode without understanding the -mv8plus flag:
After more research, it turned out that the reason for the lack of 64-bit
atomic operations on 32-bit SPARC was that gcc does not enable these
on this target unless "-mvplus8" is passed in the compiler flags. Even
setting the CPU type to V9 will not enable 64-bit atomic operations by
default.
Jan 21 2022
Could someone land this for me? Thanks!
I made another discovery which explains why passing -m32 -mcpu=v9 doesn't help.
Minor improvement to the commit description.
Updated the patch as requested and dropped all changes except the removal of sparcv9 and sparcv9__.
Made changes according to review and dropped every change except removing sparcv9 and sparcv9__.
Created a bug report for this now on Github: https://github.com/llvm/llvm-project/issues/53337
This simple hack makes it build:
Jan 20 2022
And looking at this particular GCC bug [1] again, the main problem seems that we are using __sync_val_compare_and_swap() which doesn't support 64-bit values.
I found some time again to work on this.
Jan 14 2022
Nov 9 2021
Hi! Any news on this?
Oct 28 2021
Oct 25 2021
Oct 24 2021
Oct 21 2021
Could someone land this?
Oct 17 2021
It seems we need this change on all architectures except arm, arm64, ppc64el, s390x and x86_64. Those are the only ones which implement NativeRegisterContextLinux_$ARCH.
This failure affects 32-bit PowerPC as well. Can we get this fixed?
Oct 1 2021
Aug 27 2021
@ricky26 Could you also get this fix backported in the LLVM fork of Rust?
Aug 25 2021
As suggested here [1] by @jrtc27, I think the better solution is to rename the enum Kind to KindTy.
Aug 19 2021
I tried adding -mcpu=v9 to the default build flags now:
@ro Do you have a patch for your suggested baseline raise?
Aug 17 2021
I have updated the patch to disable compiler-rt on Linux only.
Oh, another question on top: Does OpenMP work without issues on Solaris/SPARC?
Replaced by https://reviews.llvm.org/D108197
Aug 16 2021
More research reveals that the __sync_ built-ins are actually legacy stuff:
Reading through this bug report, it seems we might not be able to use __sync_val_compare_and_swap_8 on 32-bit PowerPC and SPARC:
I just realized that compiler-rt doesn't actually test on 32-bit PowerPC which would explain why we don't see the issue there:
Jul 15 2021
Jul 13 2021
Jun 18 2021
Jun 17 2021
Impressive work. Thanks a lot to everyone involved, especially to sushmaunnibhavi!
Jun 11 2021
@hvdijk Could you also later then commit the change for me? I don't have the necessary rights. Thanks!
Jun 7 2021
Apr 28 2021
Ping. Any chance we can get this in? It's the minimal approach to fix the compiler-rt build on 32-bit SPARC.
Apr 21 2021
Apr 20 2021
I could find out quickly whether the ThreadDescriptorSize for SPARC is correct but otherwise LGTM.
@hvdijk I just noticed that the sanitizer defines SANITIZER_X32 for x32, so I assume your patch itself is already correct.
This seems to have broken the sanitizer build on Linux SPARC: http://lab.llvm.org:8014/#/builders/113/builds/756
Apr 13 2021
Apr 12 2021
Hi! Can we get this patch merged as-is or do we need anything else?
Apr 9 2021
So, we only need D99988 and this one (D100148) now and the LLVM package will finally build on Debian without any additional tweaks.