I tested this patch on my glibc clang branch and while it has fixed the st_value aliases issues, it now triggers another regression:

Would avoid calling sched_yield() help in this situation? Depending of the system default, calling the glibc symbol might result in a lazy-resolution and thus invoke a lot of loader's code (which might clobber temporary registers).

This has caused a regression on stage2 buildbot [1], more specifically the test FAIL: Clang::p4-0x.cpp (but I think the other others might be related).

Hi, I am not 100% sure but it seems to trigger a regression on aarch64 bot [1]. I can reproduce with current master as well:

The change look reasonable to me, I will increase build time but it increase test coverage.

LGTM, thanks.

Updated patch based on previous comments.

In D96803#2569436, @aeubanks wrote:

In D96803#2568179, @zatrazz wrote:

In D96803#2566322, @aeubanks wrote:

why is this now a module pass?

Mainly to avoid the default rule from new pass manager to *not* apply any FunctionPass for optnone (which is the main issue for PR49143). Is there a better way to accomplish it? I noted also that createModuleToFunctionPassAdaptor basically creates a adaptor that applies the pass to all function on the module.

It's always good to make the pass as specific as possible (e.g. prefer a function pass rather than a module pass) so it doesn't have to worry about infra. For example, just iterating over functions doesn't skip declarations.

In D96803#2566322, @aeubanks wrote:

why is this now a module pass?

LGTM, it fixes the arm sanitizer regressions.

This change broke arm32 llvm-symbolizer which triggered some sanitizer regression. Previously, ARM mapping symbols [1] were ignored but after this change they are shown as the function name.

In D96490#2556620, @ostannard wrote:

The test-suite is the only thing this bot does to test global-isel, so I don't think there's any point in running the bot with this change. I think our options here are:

• Disable just the tests which are failing (looks like it's just test-suite::GCC-C-execute-eeprof-1.test?)
• Convert this to a 2-stage bot with the second stage built using global-isel, so that we are still doing some useful testing
• Disable this bot completely until https://bugs.llvm.org/show_bug.cgi?id=49143 is fixed.

Updated patch based on previous comments.

In D96337#2556270, @ostannard wrote:

Could this also affect regular users of the sanitizers, or is it specific to the way we are running the tests? If it could affect users, then could we fix this in the clang driver, so that unwind tables are turned on by default whenever the sanitizers need them?

Updated patch based on previous comments. The R_AARCH64_GOT_PAGE is added on
the isStaticLinkTimeConstant and the test is changed to check for shared build as well.

Ping.

Updated patch based on previous comments.

Patch updated from comments, main changes are:

I will update the patch, since it is incomplete and requires https://reviews.llvm.org/D94809 .

Updated patch based on previous version.

Both https://reviews.llvm.org/D93044 and https://reviews.llvm.org/D93235 have been approved, so the prerequisites of this patch are ok to land.

In D93235#2454115, @grimar wrote:

LGTM with 2 minor nits. Thanks!

Updated patch based on previous comment:

Updated patch based on previous comments:

Updated patch based on previous comments. It depends on https://reviews.llvm.org/D93235 for YAML STO_AARCH64_VARIANT_PCS support.

Updated patch based on previous comment.

Updated patch based on previous comments. For in.relaIplt / R_AARCH64_IRELATIVE
I decided to not include since it seems to what binutils is done currently. I will raise with
them if this is the intended behaviour or if R_AARCH64_IRELATIVE should also create
the dynamic tag (and fix is accordingly on lld if it were the case).

Updated patch based on previous comments.

Updated patch based on previous comments.

Updated patch based on previous comments.

In D93045#2446599, @MaskRay wrote:

st_other marked with STO_AARCH64_VARIANT_PCS indicates a may follow a variant

a -> it

In D92241#2421377, @MaskRay wrote:

Is https://reviews.llvm.org/D91733#2407055 resolved?

In D91733#2407055, @wolfgangp wrote:

Isn't COMPILER_RT_HAS_FLOAT16 generated using the host compiler? If so, using the same flag for a compiler_rt test could fail if the host compiler supports f16 and the target compiler does not.

In D91732#2404933, @ostannard wrote:

LGTM

Also, __fp16 is a storage format and promoted to 'float' for argument passing

It doesn't affect this patch, but for all of the ARM and AArch64 ABIs, __fp16 arguments are passed in the bottom half of an integer or FP register, not promoted to float. There was an old version of the AArch32 ABI (I think) which did that, but I don't think any compiler implemented it before it was changed.