[cfe-commits] Recent regression to APFloat?

[Ted Kremenek]

I isolated the problem (I believe) to APFloat.  Consider the following  
GDB session:

  426	  APFloat V (APFloat::IEEEdouble, APFloat::fcZero, false);
(gdb) n
427	  status = V.convertFromString("0.0",APFloat::rmNearestTiesToEven);
(gdb) n
429	  double d = V.convertToDouble();
(gdb) n
431	  if (isExact)
(gdb) p d
$1 = 4294967248

Notice that "d" has the value 4294967248.

Has there been any regressions against APFloat itself, or is this code  
snippet wrong (I only ask because similar code is used in clang to  
parse floating-point literals):

APFloat V (APFloat::IEEEdouble, APFloat::fcZero, false);
status = V.convertFromString("0.0",APFloat::rmNearestTiesToEven);
double d = V.convertToDouble();
std::cout << d;


On Dec 4, 2007, at 4:37 PM, Steve Naroff wrote:

> Folks,
>
> I just noticed the bug below. This seems like a fairly recent
> regression.
>
> If you've been hacking in this area (and this "rings a bell", please
> speak up).
>
> Thanks,
>
> snaroff
>
> [snaroff:llvm/tools/clang] snarofflocal% cat floatbug.c
>
> static func() {
>   float f = 0.0;
> }
> [snaroff:llvm/tools/clang] snarofflocal% ../../Debug/bin/clang -ast-
> print floatbug.c
> typedef char *__builtin_va_list;
>
> static int func() {
>   float f = 4.29497e+09;
> }