Addressed comments:

• Added a comment as suggested.

Addressed comments:

• Leave the existing handling of type code g unchanged as suggested.

Revision no longer needed now that the GO binding test code has been reverted. Thanks!

Addressed comments:

In D74163#1891408, @uweigand wrote:

In D74163#1891378, @xingxue wrote:

I'm still wondering about Intel. Can there ever be a literal encoded using 'g' on Intel? If yes, then treating it as "long double" would still be wrong, because 'g' encodes IEEE128 (__float128), while "long double" is the Intel extended (80-bit) format, right?

On the other hand, if 'g' encoded literals can never happen on Intel (or other platforms), maybe it would be better to have the code handling 'g' within a #ifdef section only active on powerpc and s390?

For X86, 'e' is used for 80-bit long double and 'g' is used for 128-bit long double. The following is the code in Clang.

clang/lib/Basic/Targets/X86.h
....
const char *getLongDoubleMangling() const override {
  return LongDoubleFormat == &llvm::APFloat::IEEEquad() ? "g" : "e";
}
...

But then this patch must be incorrect, given that it does

return getDerived().template parseFloatingLiteral<long double>();

for both the 'e' and 'g' cases on Intel. Now I guess it depends on how the file is compiled (with -mlong-double-80 or -mlong-double-128), but either way, one of the cases will be handled incorrectly.

I'm still wondering about Intel. Can there ever be a literal encoded using 'g' on Intel? If yes, then treating it as "long double" would still be wrong, because 'g' encodes IEEE128 (__float128), while "long double" is the Intel extended (80-bit) format, right?

On the other hand, if 'g' encoded literals can never happen on Intel (or other platforms), maybe it would be better to have the code handling 'g' within a #ifdef section only active on powerpc and s390?

For X86, 'e' is used for 80-bit long double and 'g' is used for 128-bit long double. The following is the code in Clang.

clang/lib/Basic/Targets/X86.h
....
const char *getLongDoubleMangling() const override {
  return LongDoubleFormat == &llvm::APFloat::IEEEquad() ? "g" : "e";
}
...

Hi @uweigand, Thanks for your comments. Please see my explanations below.

@uweigand, Hi, I've addressed your comments. Any further comments?

LGTM.

Addressed comments:

Test file aix-xcoff-data.ll needs a rebase.

LGTM.

Revised based on changes in patch https://reviews.llvm.org/D69112.

Addressed comments:

• Changed variable name CSection -> Csect;
• Added the checking of section headers in the object file.

Changed from Data to Data.Index.

Addressed comments:

• use csects in comment.
• use section storage class from CSection.
• set the section start address as the address after the previous section.

This patch needs a rebase.

Merged with the master and fixed a typo.

Addressed comments:

Addressed comments:

LGTM.

LGTM.

LGTM.

malloc(0) can be used to allocate a zero-sized object. To avoid having a null pointer to the zero-sized object, implementations often change to allocate 1 byte instead. So this patch makes sense to me.

Thanks to Marshall for committing the patch. Closing this revision.

Hi @mclow.lists, Do you have any further comments?

Hi @mclow.lists, Do you have any further comments?

LGTM.

Thanks Marshall and Hubert for your comments!

Addressed comments:

• Skip the test of midpoint of adjacent values for PPC double-double based on compile-time checking;
• Use #if defined(__PPC__) instead of #if __PPC__ ;
• Removed output to std::cerr.

Addressed comments:

• Fixed typo _XOPEN_SOUECE->_XOPEN_SOURCE

Updated comments explaining the scenario of the changes.

Added test case stdint_h.sh.cpp.

LGTM.

@hubert.reinterpretcast, @dberris, thanks for the review! I will commit once I get the permission.

LGTM.