Hello,
I’m playing with llvm/clang and I have a problem when I try to use the -ast-print options for a file that uses long double.
The Basic/Targets.cpp file defined the x86 (and x86_64) long double type as APFloat::x87DoubleExtended.
Then, when the AST printer try to write a long double literal value (using VisitFloatingLiteral()), it call FloatingLiteral->getValueAsDouble() and the later does not support long double, so it try to call convertToDouble() as a fallback and crash due to an invalid assertion. APFloat.cpp:2631: failed assertion `semantics == (const llvm::fltSemantics*)&IEEEdouble’
This is a know issue as some there is some comments like “// FIXME: We need something for long double here.” in FloatingLiteral->getValueAsDouble(), and “// FIXME: print value more precisely.” in VisitFloatingLiteral().
I wonder what will be the best way to solve those both issue. Has somebody planned to add support for long double to APInt and APFloat ?
There are no plans to support the use of host long double anywhere, if that’s what you mean.
Probably this dumper should use APFloat::convert to get the long double into APFloat::IEEEdouble format (with loss of precision; the comment claims that’s OK), then use convertToDouble on that. If you want full precision, you’ll need to print all the bits in hex; see EmitGlobalConstant in AsmPrinter.cpp.
Thank you for the reply, it give me some track to investigate.
I implemented this, thanks Dale. As a note, the preferred list for clang discussion is on cfe-dev. No harm in using llvmdev though.
-Chris
Sorry, I realised that this was not the best list afterward.
An other question about long double printing, shouldn't the printer append a 'L' suffix to long double literal ? As the printer does not output an exact value (due to the convertion to double), it will at least helps to defined that the value was correctly interpreted as a long double.
Sure, the -ast-print output should do that. The -ast-dump output is ok, because it includes the type in the dump. Note that -ast-print is incorrect for other reasons. It doesn't print the value in full precision, just an approximation as double.
-Chris