- User Since
- Jan 30 2018, 2:05 AM (147 w, 4 d)
Not sure if this is related, but on SPARC, stage2 builds recently started to fail with:
Wed, Nov 25
Yeah, @hvdijk has made multiple other improvements which should finally allow the backend to be usable.
Mon, Nov 23
Thanks so much! Would you mind pushing that change for me? I don't have commit access at the moment.
I changed it to 4.5 to be consisted with the other Multi-Arch tests for x86, MIPS and PowerPC. That's all.
Fri, Nov 20
Tue, Nov 17
Thanks a lot Rainer for taking of all of these issues on SPARC!
Fri, Nov 13
I had an extremely hard time researching the history of directory layouts for my patch D85582. Do as you like, I'm out of this.
Ping. It would be nice to get this finally merged so that the testsuite noise finally goes down on the sparc64 Linux worker.
Wed, Nov 11
I think it should be good for merging now. I addressed all remarks. I'm still convinced that "workaround" is the proper term though.
Mon, Nov 9
Merged into D90524.
Update as requested in previous review, also merge with D90549.
Sun, Nov 8
This should be merged once M68k support has been merged into LLVM, see:
Tue, Nov 3
Mon, Nov 2
Regenerated with more context (using git format-patch -W).
Sun, Nov 1
This change is required to fix testsuite failures as a result of this fix: https://reviews.llvm.org/D90524
Rebase patch for monorepo, add Debian MultiArch tests.
The previous patch accidentally missed the necessary files changes in Inputs/debian_multiarch_tree,
let's hope this one is correct now.
Update the patch to include the linux-header-search.cpp tests as well.
Update commit comment to reflect the rename of CHECK-DEBIAN-SPARC32 to CHECK-DEBIAN-SPARC.
The tests are fixed by this change: https://reviews.llvm.org/D90549.
Sat, Oct 31
Hmm, I'm not sure why the CHECK-DEBIAN-SPARC32 test is failing but I assume the expected output needs to be updated.
Please merge https://reviews.llvm.org/D90530 first, I'll update this revision afterwards.
Please let's wait with merging this as I need to make sure it doesn't break the testsuite.
Oct 28 2020
Could someone with access commit this patch for me?
Could someone with access commit this patch for me?
Rebased with latest zorg repository.
Oct 26 2020
Oct 24 2020
This patch unbreaks the build on bi-arch systems which are not x86 or MIPS, so I think it's okay to pick up the change and rewrite the code in cleaner terms later.
Replace tabs with spaces to fix indentation.
Addressed all comments and suggestions.
Oct 22 2020
Oct 19 2020
Oct 17 2020
Mar 31 2019
Well, I don't really know what to add here. The GCCDIST path on 32-bit PowerPC SUSE distributions has always been "powerpc64-suse-linux" according to SUSE's gcc maintainer Richard Biener and my patch just fixes that.
Dec 29 2018
Dec 21 2018
Dec 8 2018
Dec 6 2018
I have applied this patch to the llvm-toolchain-7 package in Debian and did not see any regressions on x86_64 or 32-Bit PowerPC. Additionally, I have included the patches from https://reviews.llvm.org/D49754 and https://reviews.llvm.org/D54409 saw no regressions on x86_64 and 32-bit PowerPC.
I have applied this patch to the llvm-toolchain-7 package in Debian and did not see any regressions on x86_64 or 32-Bit PowerPC. Additionally, I have included the patches from https://reviews.llvm.org/D49754 and https://reviews.llvm.org/D54583 saw no regressions on x86_64 and 32-bit PowerPC.
I have applied this patch to the llvm-toolchain-7 package in Debian and did not see any regressions on x86_64 or 32-Bit PowerPC. Additionally, I have included the patches from https://reviews.llvm.org/D54409 and https://reviews.llvm.org/D54583 saw no regressions on x86_64 and 32-bit PowerPC.
Dec 5 2018
Added a comment explaining the unusual triplet name.
Well, I agree on the comment to clarify why it has to be powerpc64-suse-linux, but I'm not sure whether anyone will ever start a SUSE derivative for 32-bit PowerPC, then fix the path in SUSE's gcc and then do a mass-rebuild. I think the probability is pretty low.
Oct 2 2018
Sep 18 2018
Can someone commit this, please?
Sep 17 2018
How do we move forward now?
Sep 16 2018
I was so much looking forward to this getting merged :-(.
Sep 14 2018
Great, thanks a lot! I'm also just learning how to contribute to LLVM as their setup is a bit unusual ;-).
@JDevlieghere Can you commit this fix on behalf of jrtc27? He's currently on vacation.
@LionNatsu Could you push your commit yourself or do you need someone else to push it?
Not sure how this is supposed to be tested as this requires a proper Debian powerpcspe chroot.
I don't have commit access, btw. So it would be nice if someone else could commit this for me.
Sep 13 2018
I'd be very happy to support Artyom as a co-maintainer. I assume Artyom wants to be the code owner since he already stated, he wants to develop the code at LLVM upstream.
No worries. Very glad it got finally picked up for review.
or ask someone to commit for you -- I can do so if you like.
I have pushed a rebase revision here: https://reviews.llvm.org/D52050
I don't think that "test/Driver/linux-header-search.cpp" needs to be updated. x32 is actually supported in both an x86_64-linux-gnu environment and x86_64-linux-gnux32 environment. In order to update test/Driver/linux-header-search.cpp, we would have to add a debian-10-x32 chroot to the LLVM test environment. However, the patch by @jrtc27 actually doesn't break the previous tests as his patch just allows the native header and library paths as altnernative search paths.
I have just rebased the patch and I am looking at the tests now.
@m4yers I think you need to add reviewers here as well, no?
Has this been merged now? I don't see it in the github mirror yet.
Sep 11 2018
Ok, thanks for the explanation. I wasn't sure how it's handled in LLVM. I'm in the OpenJDK upstream project and we always require two reviewers for changes to Hotspot!
Does this still need a review from cuviper?
Aug 30 2018
Aug 27 2018
This patch fixes a problem with Rust emitting code with causing unaligned access: https://github.com/rust-lang/rust/issues/53181
May 13 2018
Is there any chance this PR can get completed?
Feb 28 2018
As a heads-up, powerpcspe needs a similar treatment as it suffers from the same problem:
Feb 20 2018
Cool, thank you! \o/