In D127953#3610485, @JamesNagurne wrote:

In D127953#3610109, @Mordante wrote:

I'm not precisely sure what you mean by 'which tool', but here's a reproduction using a cut-down reproduction of the standard test using clang trunk with libc++

https://godbolt.org/z/jYs7Pz8qj

Poke CI.

Rebased
Addresses review comments
Updates the release notes to the latest style

Thanks for the review!

With the CI green, reenable all CI jobs.

More CI fixes and disables more green CIs

More CI fixes.

@ayzhao, @cjdb Thanks for the additional information.

More CI fixes.

In D127953#3609091, @JamesNagurne wrote:

I'm curious about how we handle proposals in the working group.

https://cplusplus.github.io/LWG/issue3378

Suggests that some of the same language applies to the tuple helpers when including array, etc. Some industry-standard conformance tests are checking for the behavior defined in issue 3378.

Attempt to fix buildkite

Fixes some CI issue.
Note temporary disable quite some CI runs, since I expect several non-Linux systems to still fail.

Thanks for working on this. I did a shallow review and hope to find time for a more in depth review at another time.

Fixes CI.

In D128139#3597167, @ldionne wrote:

This patch seems to be moving around quite a bit of code. Would it be possible to do some of the reorganization before this patch as a NFC to ease reviewing this?

In general I'm happy. But please avoid unrelated NFC code changes is these kind of commits. Especially since the title nor the description mentions them. (Thus some minor whitespace fixes are not an issue.)

Rebased and addresses review comments.

SGTM, but for now I prefer to leave the approval to people more familiar with the details of this patch and AIX.

Thanks for the review!

In D128021#3603708, @itrofimow wrote:

In D128021#3593922, @Mordante wrote:

Would this example be enough?
I could've messed up compile flags, and guidance would be appreciated if i did so

In D127226#3602787, @manojgupta wrote:

This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.

LGTM!

LGTM when the CI is happy.

Poke CI.

Poke CI

Thanks! I see different errors now. I'll see what I can do about it. At the moment our CI is rather unstable so I'll look at it when that's fixed.

Rebased and addresses review comments.

Thanks for the reviews!

Thanks for working on this!

Final polishing, when the CI passes I'll land this version.

In D128215#3597096, @philnik wrote:

Yes we still support 32-bit platforms, using a 64-bit value there would give a performance penalty, especially on platforms with a small number or registers.

Isn't size_t 32 bits wide on 32-bit platforms?

Another reason why I prefer 32-bits is that I'm quite sure that division of a 32-bit value by a constant is more efficient than the division of a 64-bit value. (The compiler will transform it in a multiplication and a shift which IIRC always fits in a 64-bit register, when using a 32-bit value.) This is what we're doing for base 10.

Could you do a benchmark to check if using a 32-bit wide instantiation yields better performance even on 64-bit platforms?

Fixes C++03.

tab -> space.

tab -> space

An experiment to fix the CI issue.

Rebased and adresses review comments.

In D124569#3578931, @saugustine wrote:

I can't manage to get the buildbot environment working to test this. It consistently fails with

clang: error: unable to execute command: posix_spawn failed: Operation not permitted

Not sure the best thing to do here. I think it should work fine, but am stumped on how to test it.

Thanks for working on this! I think this is really useful to have. The makes it easier to remove includes from subheaders and see whether that as a user visible impact.
I'm a bit curious whether it will cause a lot of build failures. (I know it shouldn't.)

In D128087#3594642, @xingxue wrote:

Thanks very much, @Mordante and @philnik! There isn't an AIX maintainer IIUC but I will wait a couple of days to see if other reviewers have any comments. Thanks again!

Thanks for working on this, LGTM! Please wait for one of the AIX maintainers to approve too.

Addresses all review comments and rebased.
Make sure the CI passes since during the last iteration the CI was down.

Thanks for the reviews!

Removed the parent commit and test again with -Wno-tautological-compare.

Thanks for the review!

LGTM once the CI passes. I think it would be good for @ldionne to also have a look so I leave the final approval to him.

In D128215#3596983, @philnik wrote:

Is there a reason to not just instantiate it for that largest integral type? Or size_t and the largest integral type to avoid using multiple registers for smaller types?

Thanks for the review!

In D89057#3595320, @mmuetzel wrote:

Is this still being worked on? It would be nice (from a user point of view) if this could be in one of the next releases of libc++.

Try restarting CI.

One request, when you address a review comment, can you check the "done" button this makes reviewing easier.

In D128084#3593506, @arichardson wrote:

I have some WIP patches for the locale tests that I should update . I'm not sure how long it will take to fix all the tests so maybe xfail is better so that regressions are caught?

LGTM, but please wait for approval of an AIX maintainer.

Address review comments.

LGTM, but please give other reviewers a bit more time to have a look.

Thanks for the review!

@infrandomness thanks a lot for providing this CI runner!

Thanks for working on this!

I've rebased the GCC-12 CI changes (D126667) on top of this one and the GCC CI is happy (https://buildkite.com/llvm-project/libcxx-ci/builds/11560).
So that means the only tautological comparison issues where the constant evaluated messages.

Thanks for your contribution! I'll have another look after all comment have been addressed.

No real objection, but I think having an XFAIL will give us feedback when modules start working with modules.

LGTM after the CI passes. I leave the final approval to @philnik since he also had some comments.

In D127953#3590508, @saugustine wrote:

I can't speak to the testing issues--perhaps it would be good to add them in a subsequent change. But getting correct code working again would be really good, and what is here addresses that.

LGTM, thanks!

@ldionne I've the suggested changes, but before putting it up for review again I want to see whether these changes impact other work-in-progress code. (Not merge conflicts, but incompatibilities.)

LGTM when the CI passes.