[libcxx-commits] [PATCH] D74163: [demangler] Fix the parsing of long double literals for PowerPC and S390
Ulrich Weigand via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Feb 25 07:52:06 PST 2020
uweigand added a comment.
In D74163#1891378 <https://reviews.llvm.org/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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D74163/new/
https://reviews.llvm.org/D74163
More information about the libcxx-commits
mailing list