LGTM, thanks!

Let's document the option as well under: https://clang.llvm.org/docs/ClangCommandLineReference.html#powerpc

Thanks, LGTM from the AIX perspective (noting though this benchmark was actually disabled for AIX by https://reviews.llvm.org/D103063 for other source issues)

LGTM, with a small nit about the test that should be addressed before committing

Reopen since this was reverted

In D126122#4173881, @arcivanov wrote:

@daltenty I applied the same exclusion logic llvm_setup_rpath in AddLLVM.cmake and the build is now fully passing.

Produce a diagnostic if the options are used with non-AIX targets

Since https://reviews.llvm.org/D142842 still needs some revision to be ABI-safe, and this was already good to go, we'll proceed with this patch and D142842 can rebase against it if there are no objections.

This patch is failing in the libc++ precommit CI attached to this revision as the -rpath option is unsupported on AIX:

LGTM, thanks!

It seems there's actually some work going on at the present time to re-work how constant data like this is structured in the XCOFF codegen (e.g. to do some pooling). This patch is likely to conflict and/or be superseded by that approach, so I'm going to put this on hold for the moment till that refactoring lands and we see whether this is still relevant.

LGTM for AIX

In D134282#4151773, @hubert.reinterpretcast wrote:

In D134282#4148884, @hubert.reinterpretcast wrote:

Not that I know of without negative side-effects. For example, if we access using a TOC entry for a label for the individual string, we would end up with more TOC entries which, in turn, can lead to TOC overflow.

Looking at a case with more than one string, it seems we currently have separate csects and TOC entries for each string anyway. I am not sure that is a state we want to stay in though.

In D134282#4148884, @hubert.reinterpretcast wrote:

In D134282#4148337, @efriedma wrote:

Is there any way we can make AIX targets more resilient handling this kind of alignment change? If we have to, we can choose a point after which passes aren't allowed to increase the alignment of globals, and move this transform before that. But I'd like to avoid that if possible.

Not that I know of without negative side-effects. For example, if we access using a TOC entry for a label for the individual string, we would end up with more TOC entries which, in turn, can lead to TOC overflow.

Here's an IR only example which will exhibit the invalid AIX assembly after this change:

target datalayout = "E-m:a-i64:64-n32:64-S128-v256:256:256-v512:512:512"
target triple = "powerpc64-ibm-aix"

In D140675#4132958, @philnik wrote:

Sorry for chiming in so late, but I've got D142842 to remove _LIBCPP_ABI_BAD_FUNCTION_CALL_KEY_FUNCTION. IIUC that should also fix your problem, right?

Unfortunately, some of this doesn't really work on AIX linkage model. Specifically, the linker doesn't follow the resolution semantic of trying to resolve weak references locally first that you see on other platforms (we have an option -bweaklocal to enable that), so we prefer the strong def we see in the library. This means this assumption doesn't hold on AIX:

Latest format changes LGTM. Small nit about the test comment.

LGTM, with a minor tweak

LGTM, with some minor nits to address before commit. Updated the description to describe the details of the issue.

In D142727#4091417, @DiggerLin wrote:

you means that if there is no define of -DCMAKE_RANLIB= , the CMake (versions >= 3.22) will use llvm-ranlib by default?

LGTM, with small nit to address before commit

Some minor nits about how we can shorten the test, but otherwise LGTM

Looking better, still needs a test though.

Needs a test, I think we should add a couple of -fopenmp=foo run lines to clang/test/Driver/aix-ld.c to verify that the correct linker options are produced for each.

LGTM with new IN_LIST update

The discussion about the meanings of these things should be taken to Discourse, not buried in a couple of patch reviews, in any case.

I believe @phosek documents the intended semantic here in https://reviews.llvm.org/D137451:

LGTM, thanks!

LGTM. Some paths in compiler-rt still require LLVM_TARGET_TRIPLE, so commoning the setup makes sense

In D138864#3956057, @phosek wrote:

What's the issue you're trying to address? I just landed D137451, does it address your issue?

This broke the AIX CI: https://buildkite.com/llvm-project/libcxx-ci/builds/15656#0184eac6-521b-4d1e-8502-c226673e0ece. Unfortunately it seems the .irp directive isn't supported by the AIX assembler.

New revision LGTM, VisibleNoLinkage is typical reserved for types from inline functions so it doesn't seem sensible to return. Looking at the C++ standard, I'm not even convinced this is guaranteed to be the same object if the function doesn't have external linkage, so I think the guard is sensible.

This patch seem to do a bit more than it's description implies. It makes LLVM_DEFAULT_TARGET_TRIPLE no longer an valid option on the runtimes path:

CMake Warning:
  Manually-specified variables were not used by the project:

In D130327#3944591, @vsapsai wrote:

In D130327#3944188, @NancyWang2222 wrote:

@vsapsai hi Volodymyr Sapsai , test case clang/test/Modules/hidden-duplicates.m is failing on our llvm community AIX box https://lab.llvm.org/buildbot/#/builders/214/builds/4442/steps/6/logs/FAIL__Clang__hidden-duplicates_m , it gives exit code 70 without detail error message, can you help fix it as soon as possible. Thanks

Does AIX have support for compiling Objective-C? I'm not entirely sure that's the right fix but many tests have // UNSUPPORTED: -zos, -aix, so I'm inclined to disable the test for AIX.

LGTM, thanks!

In D137110#3916097, @philnik wrote:

In D137110#3899667, @hubert.reinterpretcast wrote:

In D137110#3899449, @ldionne wrote:

But first, I'd like to understand why you're not setting CMAKE_CXX_COMPILER to the compiler you're trying to run the tests with?

Is my understanding correct that changing CMAKE_CXX_COMPILER also changes the build compiler for the shared libraries?
The intention is to build using a "stable" compiler, but still allow testing with a compiler under development.

Why can't you compile the library with the experimental compiler? If it can't properly compile that, it surely can't run the test suite.

LGTM. Doing the inner computation while observing visibility seems like the right thing to do in this case.

We've rolled the tests added by this into https://reviews.llvm.org/D135885 instead, so abandoning this.

These adjustments were added in https://reviews.llvm.org/D134221

Seems like this is breaking in the libc++ CI: https://buildkite.com/llvm-project/libcxx-ci/builds/14027

Remove __gcd from the patch, as the always_inline we use in the macro for gcc causes problems in this recursive case.

In D134221#3850412, @ldionne wrote:

Rebase and address AIX issues.

@daltenty I already had this update ready to go before you created D135699, but let me know if you'd
rather go with yours instead, which is in a separate patch. I have no preference but I did find that
my comment explaining the issue was a bit more detailed.

Add newline to end of file

LGTM, thanks for accommodating this change. Should help solve some problems for us.

Do you mean that both unwind_shared and unwind_static both create a target named libunwind.a?