I am aware of the 80bit float limitation of valgrind, but I am confused by the inconsistent behaviour shown by the test case following. As I understand the documentation, 80 bit floats are treated as if they were 64 bits, so generally the results should be the same provided that the numbers do not require high precision. The following testcase is Ada code, compiled with GNAT pro 5.05 on an uptodate debian unstable. The command to compile is "gnatmake main". The source file should be called main.adb. The output without valgrind is: ./main 1.59990000000000000E+01 1.60000000000000000E+01 1.60000000000000000E+01 valgrind ./main (cut) 1.59990000000000000E+01 1.60000000000000000E+01 1.00000000000000000E+00 It seems that the conversion to 64 bit works correctly with a constant but not with a local variable. File: main.adb with text_io; use text_io; procedure main is type simple_float is new long_long_float; g : simple_float; f : simple_float; h : simple_float; begin g := 15.999; f := simple_float'ceiling(simple_float(15.999)); h := simple_float'ceiling(g); put_line( simple_float'image(g)); put_line( simple_float'image(f)); put_line( simple_float'image(h)); end main;
Closing this now having established that it is caused by an Ada run time routine for FP truncation that relies on 80-bit FP arithmetic working (it adds and subtracts 2^64 to force anything to the right of the decimal point to fall out of the mantissa).
*** This bug has been marked as a duplicate of bug 197915 ***