In D65667#1643305, @EricWF wrote:

That doesn't need to happen now. But I want to see these changed to be global statics not function local. At least that way we omit the guards entirely. and accessing the variable becomes a single instruction.

Looking through this latest version still (this is a largish patch).

In D65667#1642281, @EricWF wrote:

Sorry for being late to the party, I've looked at the codege of this and other approachs. what we want is a single global than initializes all of objects we need. Right now we have function local static then may may not have make guards and that's less than ideal.

A few small changes, but otherwise LGTM.

I'm not seeing unresolved comments. This patch LGTM.

LGTM.

In D64817#1638218, @tstellar wrote:

Which version of RHEL is this patch meant for? Since the jump to C++14, on RHEL <= 7, you will need to compile llvm with the devtoolset toolchain, which has a newer version of binutils. This fix is probably only needed on the release/9.x branch (which can still be built by the system toolchain on RHEL7) and not trunk.

It is possible to build with Clang and libc++ and not use a newer version of binutils for trunk.

Is this the use case this patch is intended to fix?

In D64817#1638218, @tstellar wrote:

Which version of RHEL is this patch meant for? Since the jump to C++14, on RHEL <= 7, you will need to compile llvm with the devtoolset toolchain, which has a newer version of binutils. This fix is probably only needed on the release/9.x branch (which can still be built by the system toolchain on RHEL7) and not trunk.

Related to the 32-bit vs 64-bit naming and assertions: I can appreciate being defensive about this, but I think trying to disable being able to create the various types and having an assertion (or error) in every function is overkill.

This patch LGTM.

In D65667#1617952, @thakis wrote:

To chime in from the sidelines: We strive to have zero code that runs before main in Chromium, so we're not excited about a patch that adds more such code to libc++. (In fact, we're hoping to contribute a build mode that removes the existing static initializer for cin/cout/cerr as well.)

Fix spelling error

Address comments: Split large GCC-compatible options block

In D66256#1630348, @jfb wrote:

I'm worried because this entire section is for "GCC compatible command line stuff". If someone added something new in there, would it inadvertently break XL? Maybe it's better to factor out the bits you want to enable and leave the rest separate from XL?

In D66256#1630326, @jfb wrote:

Can XL enable all the same flags which GCC can?

I am still working through this version, but I think this might need another pass on an updated copy.

My attempt to commit this only committed the test. I'll try again once the bots clear.

LGTM with a minor issue that can be fixed on check-in.

@Xiangling_L, I'd be happy to work with you on this off-list to move this along.

LGTM.

In D65667#1619105, @mclow.lists wrote:

Thanks for the clarification.

So the situation is:

• You register an atexit handler.
• During program termination, your handler is called, and you do something that creates an error_code object.
• You try to use the error_category of that error code, and discover that it has been destroyed?
  
  Is that correct?

This patch needs a rebase. It no longer applies cleanly.

In D65667#1617183, @mclow.lists wrote:

Hubert - I'm not following what you're saying.
Where did error_code come from? As far as I can tell, your comment is the first mention of error_code in this conversation.

In D65667#1615205, @mclow.lists wrote:

The good news is that the constructor of the singleton object in libc++ is under your control. It can be constructed whenever you choose, just by calling generic_category().

Addrew review comments: Output and check the byte values only

In D65667#1613503, @mclow.lists wrote:

@EricWF pointed out to me that it is UB to access standard library objects of static storage duration from an atexit handler: http://eel.is/c++draft/basic.start.term#6

In D65680#1613484, @MaskRay wrote:

Can you just dump the output of od -t x1 -v -j 0x3a -N 1 %t3 on AIX? That would be more descriptive I think. It also helps us decide how to test.

In D65671#1613487, @MaskRay wrote:

Is there a plan that AIX od will implement x8?

I've requested the change, but I cannot make any promises on delivery vehicle.

In rL363829#676214, @MaskRay wrote:

I think the description should ideally give an output example of AIX od. Many developers are not familiar with its output format.

In D65680#1613409, @grimar wrote:

rL364517 introduced further instances of od output checking of the kind previously corrected by rL363829.

I leaved a comment for rL363829, it seems broke at least one of the tests.

I've answered the question asked in rL363829.