Bug 130358

Summary: Inconsistent 80-bit floats on x86
Product: [Developer tools] valgrind Reporter: Ian Broster <ianb>
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED DUPLICATE    
Severity: normal CC: philippe.waroquiers
Priority: NOR    
Version: 3.1.1   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:

Description Ian Broster 2006-07-06 14:56:07 UTC
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;
Comment 1 Julian Seward 2006-07-17 12:22:33 UTC
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).

Comment 2 Philippe Waroquiers 2013-03-05 21:07:56 UTC

*** This bug has been marked as a duplicate of bug 197915 ***