@daltenty @xingxue
Since I don't have access to AIX machine any more, would you help to test and land this patch if this still aligns to what you want on AIX?
If not, feel free to commandeering this patch if needed.

In D100777#2911594, @mstorsjo wrote:

In practice, which cases didn't work as they should in that configuration before? I haven't noticed that aspect anywhere in the libc++ tests on Windows (although it could be hidden by some XFAIL: LIBCXX-WINDOWS-FIXME, but that would show up as XPASS in that case too).

Rebase to trigger CI.

Ping.
@ldionne Any comments?

Ping.
@ldionne Any comments?

Ping.
@ldionne any comments?

LGTM. Thanks.

is_lock_free actually returns false for this structure:
struct LLIArr2 { long long int i[2]; };

LGTM. Thanks!

LGTM; Thanks!

In D85774#2801934, @jhenderson wrote:

Looks good again. Sorry for the delay - I was off work last week.

LGTM on AIX perspective.
FYI, we will need two reviewers from libc++ review group or the maintainer of libc++ project to approve before we could land.

Adjustment the print out.

Good idea, fyi, this is the patch: https://reviews.llvm.org/D83252

LGTM.

Address comments.

In D85774#2758956, @jhenderson wrote:

I took a quick look at the pre-merge output. The message is that the object isn't recognised as a valid object file, not that it wasn't found, which suggests either the object or code is broken in some manner, or you're missing a dependent patch. Does this patch depend on another patch that isn't in main yet?

Address comments.

Address comments.

Address comments.

It would help if we could put the sample invocation in the summary.

Gentle ping.

Updated test case to account for short wchar_t.

In D85774#2738969, @jhenderson wrote:

In D85774#2738962, @jasonliu wrote:

@jhenderson @DiggerLin @Esme
Any more comments?

I'll try to take another look in the next day or two. The pre-merge bots are failing. Is that an issue with this patch?

@jhenderson @DiggerLin @Esme
Any more comments?

Ping.

Address comments.

Address comments.

As expected, this changes the behavior of windows platform for the do_length and do_max_length of __codecvt_utf8<wchar_t>.
But I think the changes are actually desired. Could anyone working on Windows platform confirm that?
If we could agree on that, then I could work on updating the test case.

Address comments.

Address comments.

rebase to clean the pre-commit ci

Ping.

Address clang-tidy comment and added binary file.

In D100777#2709968, @jasonliu wrote:

In D100777#2707189, @SeanP wrote:

Why did you have to add a specialization based on size? Could you provide a test case or two to help explain. My first thought is the _LIBCPP_SHORT_WCHAR macro should be good enough since aix & z/OS only support one wchar_t size per 32/64 bit mode.

With -fshort-wchar, you could have a short wchar in 64 bit mode. So this implementation still gives you the correct result if that's used.

Gentle ping for libc++ group's review.

Gentle ping.

In D100777#2707189, @SeanP wrote:

Why did you have to add a specialization based on size? Could you provide a test case or two to help explain. My first thought is the _LIBCPP_SHORT_WCHAR macro should be good enough since aix & z/OS only support one wchar_t size per 32/64 bit mode.

Rebase and Address comments.

@Esme I will rebase and address comments asap.

Abandoning this patch in favour of the approach in https://reviews.llvm.org/D100410.

rebase.

Run clang-format and hopefully it fix the pre-commit CI.