In D55326#1342412, @nemanjai wrote:

A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation:

• We seem to be changing the set of aliases here, but what happens if someone actually explicitly specifies --target=powerpc-suse-linux?

In D54409#1342394, @nemanjai wrote:

Other than the minor nit about the test case, LGTM.

In D49754#1339161, @vit9696 wrote:

Ok, I found the fix for the first crash that landed in 8.0 trunk. It works fine for me if backported to 7.0.1:
https://reviews.llvm.org/D50461

In D49754#1323642, @vit9696 wrote:

Might the first crash from https://reviews.llvm.org/D49754#1183753 reproduce for you or perhaps you have already bisected to trunk to figure out the changest that fixes it?

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.

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.

Hi Kristina!

Can someone commit this, please?

How do we move forward now?

I was so much looking forward to this getting merged :-(.

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.

Hi Chandler!

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.

Hi Kristina!

Hi Kristina!

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.

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?

This patch fixes a problem with Rust emitting code with causing unaligned access: https://github.com/rust-lang/rust/issues/53181

Is there any chance this PR can get completed?

As a heads-up, powerpcspe needs a similar treatment as it suffers from the same problem:

Cool, thank you! \o/