Thanks @e-kud, LGTM.

Test case changes look good to me.

I checked no difference in codegen between /EHa and /EHsc in MSVC. So it should be correct for clang as well.
We should land it ASAP since it fixes a crash case.

In D102817#4079631, @victork1996 wrote:

Hi @tentzen :)
I compiled clang's main branch after applying these changes, and I think I found a bug.
I tried to compile the following code with the "-fasync-exceptions" flag and the compiler crashed :(
can you take a look?

void foo()
{
    try
    {}
    catch (...)
    {
        // The 'return' statement causes a crash, it compiles just fine without the 'return'.
        return;
    }
}

thanks :)

LGTM.

FYI, I just got in touch with @tentzen. He is not working with this now, but he said the revert is just a mistake.
I suggest we reland it as is if no strong objections from other reviewers.
We have customers that looking forward to it as well. I'd like to work with community for the followups.

LGTM.

LGTM.

LGTM.

We had an offline discussion on this. I generally got the idea of the design. Let's land it first to see if there're unconsidered cases.

Tested this with cases in #60914. Both got segmentation fault. I think this should not be a correct fix.

LGTM.

LGTM.

In D145634#4194990, @e-kud wrote:

In D145634#4187914, @pengfei wrote:

In D145634#4187888, @e-kud wrote:

In D145634#4183847, @pengfei wrote:

Do you have plan to support minimumNumber?

Sorry, I didn't get it. Could you be more specific?

It's accompanying function of minimum in IEEE-754 2019, it will be introduced in new C/C++ standard too. I thought you are working for that.

I can't find any lib calls or specific intrinsics for them. I'd like to add them separately if we have any users or needs of them, do we?

Add test case.

Convert one more uint64_t Align into Align Alignment.

Address review comment.

In D145634#4187888, @e-kud wrote:

In D145634#4183847, @pengfei wrote:

Do you have plan to support minimumNumber?

Sorry, I didn't get it. Could you be more specific?

Support i886 and i986.

Only make OS override i386.

The negative comparison is not correct.

Address review commnets.

X86 tests change looks good.

Fix lit failure.

Fix typo & add tests.

In D145857#4186957, @craig.topper wrote:

Did you test this? I kind of expected the triple would be normalized before this. I’m not at a computer to check.

LGTM.

Do you have plan to support minimumNumber?

In D136919#4174513, @stuij wrote:

FWIW, at Arm we decided to keep the old name mangling to minimise friction with existing code/libraries, but allow more operations with this same name-mangling. We also discussed with Red Hat and they were ok with this.

In D142287#4167017, @kalcutter wrote:

Do you know what gcc does here?

Could you memcpy the __mmask64 into the byte buffer?

I think gcc does the same thing as clang. In both cases the issue can be observed with UBSAN.

memcpy can be used as a workaround but it is less ergonomic since both arguments are pointers which means it can only directly be used with lvalues. memcpy is also less explicit.

Intel's documentation of _store_mask64 does not specify any kind of alignment. Also, they document this intrinsic as being kmovq m64, k which has no alignment restrictions. I don't think it makes sense for intrinsics to enforce an arbitrary stricter alignment than instructions they represent.

Thanks for the fix, but I may not be qualified to approve.

I'm confused. Isn't the patch identical to D143786?

Is this substituted by D144570?

LGTM.

LGTM.

I don't think there exists such an API. We don't record such information for each instruction.

Looks great!

Should asm volatile ("nop"::"S"(405):); be asm volatile ("nop"::"b"(405):);?

In D144282#4138035, @goldstein.w.n wrote:

In D144282#4137911, @pengfei wrote:

Can we add tests on demand? It looks to me there are tests neither touched by D144283 nor D144284.

There are some intentionally not touched tests *fail*. Would you prefer I drop some of them?

Can we add tests on demand? It looks to me there are tests neither touched by D144283 nor D144284.