Bug 130358 - Inconsistent 80-bit floats on x86
Summary: Inconsistent 80-bit floats on x86
Status: RESOLVED DUPLICATE of bug 197915
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.1.1
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-06 14:56 UTC by Ian Broster
Modified: 2013-03-05 21:07 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***