I've added support for x86_32/i686.

In D126484#3542066, @thakis wrote:

Looks like this breaks tests: http://45.33.8.238/linux/77072/step_11.txt

Please take a look and revert for now if it takes a while to fix.

Sorry, but I've missed some updates for LLD tests requiring zlib. Working on the fix now.

@mgehre-amd this has broken our Linux GCC And Windows MSVC builds. Both complain that:

.../compiler-rt/lib/builtins/udivmodei5.c:27:32: error: initializer element is not constant
 static const su_int WORD_MSB = (su_int)1 << (WORD_SIZE_IN_BITS - 1);

Also __attribute__((weak)) is not supported for MSVC.

Address review comments.

Ping.

Abandoned in favour of D114179.

This is potentially a "better" alternative to D114103.

Updated to address review comments.

Managed to end up here after looking at the query on D70447. Should this patch be cherry picked to the llvm-13 release branch?

Address review comments and moved testing to x86-64-tls-ld-local.s.

In D111436#3051813, @MaskRay wrote:

Please place this in one of the x86-64-tls-ld*.s files. For ppc64 we use ppc64-dtprel.s

Replaced negative checks with checking that there is no output from --print-icf-sections using count.

Looking at some of the other ICF tests, another approach to checking for no merging is: ... --print-icf-sections | count 0. Would this be preferable to using CHECK-NOT: patterns?

Added comments to tests.

Added comment to test as suggested off-line by @jhenderson.

I looked into this in some detail back in the day and am mainly responsible for how this thread pool currently functions. I primarily focused on static linking with the MSVC static runtime, as that's what we use downstream and were seeing issues with, but also included MinGW, GNU and libc++. To be honest, I can't remember if I tried LLVM_LINK_LLVM_DYLIB, there are just too many possible configurations! The various compilers/runtimes have changed since I last looked at this code, so it's not surprising that there may be issues depending on your configuration.

Updated to address review comments.

Apart from the nits already pointed out by @jhenderson, LGTM.

This change broke one of our downstream tests and the issue can be reproduced with the following test:

# REQUIRES: x86

Update to clarify the purpose of the initial call to writeSymbolTableHeader.

In D89789#2345015, @MaskRay wrote:

Putting together, I think this option cannot be accepted.
On the good side, the place you modify is very stable and you usually will not get merge conflict.

In D89891#2345374, @MaskRay wrote:

I understand that a test may be problematic because it requires 4+GiB output. Do you have a script to craft such a test case so that people working on llvm-ar can run it on demand? The test can have UNSUPPORTED: *.

Updated to address review comments and updated to add better testing. Whilst adding this testing, found another bug in the detection code; it was also not accounting for the size of the file signature!

Ping.

In D88830#2313269, @MaskRay wrote:

The description can be shortened a bit. The important part is that variableEq returns false if two relocations reference a pair of aliased symbols in an ineligible section.

Address review comments.

Abandoning due to lack of interest and in favour of D88830 which requires these changes.