Double checked re: scope of __ABS_LONG__. Confirming LGTM re: AIX context.

From what I understand, this is meant to fix a situation where dbx is unhappy when the file is not simply compiled in the directory where it resides (using its basename). However, this unhappiness extends even to the compiled-using-basename case when the filename contains "special characters".

LGTM; thanks!

I have just some typo/phrasing fixes to suggest. I think my other concerns have been addressed.

LGTM; thanks.

In D97558#2648876, @jasonliu wrote:

@hubert.reinterpretcast Does the freelocale approach look good to you?

LGTM with small suggested changes.

LGTM; thanks!

LGTM; thanks.

@NancyWang2222, the patch description doesn't seem to say much about the bit-field case. Can you expand it?

LGTM; thanks!

@edwin, the patch needs to be updated with additional diff context.

LGTM (with the equal sign form as @daltenty requested if it works).

LGTM; thanks.

Retained using declarations look fine. LGTM.

GCC doesn't seem to implement this as a keyword?

namespace Q { int __ieee128; } // compiles

Thanks @Xiangling_L and also to the other reviewers for the great comments. This LGTM.

Committed: https://github.com/llvm/llvm-project/commit/4f9cc15

Will commit a revert.

LGTM; thanks.

In D97748#2607182, @Kai wrote:

there are some implications with char/string literals inside an inline asm string

In D97748#2604956, @anirudhp wrote:

And the current implementation here expects UTF-8 (or that's what the internal character encoding is assumed to be anyway). There's a patch for -fexec-charset and the string being parsed here went into the IR in what form?

Currently, the asm string goes into the IR in ASCII, irrespective of the -fexec-charset option.

In D97748#2600624, @anirudhp wrote:

For now, We don’t have a firm decision on whether we will implement/support pragma convert. I understand that if it is supported, it will be a problem since the character values for the national characters will be different based on the encoding. At a future point, when we have more information, we can come back and review whether certain applicable functions would need to take the encoding into account, or, whether it can be designed in a way such that for example, everything is encoded in UTF-8 and the emission/translation is handled elsewhere (preferably much earlier than the respective backend). For now, I'm assuming the current implementation is fine.

In D97748#2597782, @anirudhp wrote:

An additional point:
I checked the V1R6 Reference manual again and I seem to have forgotten to include a check for "National Characters" ($,@ and #). I would like to remedy this by adding two private inline functions isHLASMAlpha and isHLASMAlnum which encapsulates the checks for what is an "HLASM" alphabet, and use them in the overridden isLabel routine. Is this acceptable?

LGTM with an additional comment wording change.

The resolution of LWG 2828 means that <cstdalign> exists in C++11 and C++14. The rationale from https://reviews.llvm.org/D96786#2566110 can be taken as saying that adding this header for C++11 conformance is reasonable.

LGTM with minor comments.

LGTM with minor comment.

In D95518#2556452, @jmorse wrote:

Drive by comment,

Object output will be handled in followup patches.

[...]

Since I can not get the assembly file been assembled, I verify the debug info by checking the assembly files.

LGTM with minor comments on the test.

In D95444#2542739, @rnk wrote:

Clang actually supports mixing GCC and MSVC inline asm in the same translation unit, and it uses the dialect flag in the IR to control this (I think). This is important if you want to support LTO between two TUs that use GCC and HLASM. Maybe there is exactly zero inline asm that uses GCC-style asm for SystemZ, so maybe this isn't a concern, but I thought I'd ask.

From my end, LGTM.