In D94670#2501886, @MaskRay wrote:

Seems that the error is expected, as gas/config/tc-ppc.c says:

In D94670#2501886, @MaskRay wrote:

So how does your example work?

In D94670#2500677, @shchenz wrote:

2: On AIX, the assembler does not need the assembly file contains the dwarf sections length info in the dwarf section header(if the dwarf section has header.) Instead, the assembler will insert the calculated length into dwarf sections header of the final object according to DWARF type. Namely AIX assembler will insert 4 bytes in each section header for DWARF32 and 12 bytes for DWARF64.

• Address review: Mention plain char only when it appears

In D93177#2487304, @tambre wrote:

I reverted (D94319) and now re-landed (D94322). Seems the check for empty CMAKE_BUILD_RPATH got incorrectly reverted when I addressed the review comment.

Ping, @aaron.ballman?

We're seeing:

CMake Error at cmake/modules/AddLLVM.cmake:861 (add_executable):
  The install of the verify-uselistorder target requires changing an RPATH
  from the build tree, but this is not supported with the Ninja generator
  unless on an ELF-based platform.  The CMAKE_BUILD_WITH_INSTALL_RPATH
  variable may be set to avoid this relinking step.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:1209 (add_llvm_executable)
  tools/verify-uselistorder/CMakeLists.txt:10 (add_llvm_tool)

LGTM; thanks.

In D93377#2481312, @rjmccall wrote:

Are you committed to the name __ibm128?

LGTM with comments; thanks.

Thanks; the targeted fix for handling realpath (where we have experimentally verified that the operation does fail with paths longer than 1024) seems reasonable to me. Looks good from my end.

Confirming LGTM.

LGTM; thanks.

LGTM with comments.

2. AIX uses a new personality routine, named __xlcxx_personality_v1. It doesn't use the GCC personality rountine, because the intractability is not there yet on AIX.

In D92324#2423833, @sfertile wrote:

If the best CPU to target for a PPE is one of the ones modified in this patch, they can still do so, but will have to explicitly add -mattr=+altivec when invoking llc.

That sounds okay.

The altivec feature was an optional part of the 2.03 (pwr4) and 2.04 (pwr5) ISAs, and it was not implemented by any IBM CPUs until Power6.

The Power Processing Element in various IBM CPUs (including the Cell Broadband Engine) incorporate VMX. With this change, which of the CPU options should a user targeting a PPE use?

Reverting this patch makes va_arg with the default 128-bit (double-double) long double work again:

#include <stdarg.h>
void abort(void);

LGTM.

This is a really old patch that I had in my usual build tree and needed to manually rebase recently.
It might be helpful for someone, but I think the original context where I developed it is not exactly the build configuration I wanted.

Rebase

LGTM; thanks!

LGTM; thanks.

LGTM; thanks!

LGTM; thanks!

LGTM; thanks!

LGTM; thanks.

In D89758#2340716, @hubert.reinterpretcast wrote:

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

In D89684#2341922, @hubert.reinterpretcast wrote:

-mabi=aixvecextabi was suggested when I discussed this with someone who is familiar with GCC. The choice of extabi at the end is to match the spelling of the __EXTABI__ macro.

I have two concerns over the choice of the option form/name.

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.