Bug 12059

Summary: jcf-dump does not display float constants to fixed precission
Product: gcc Reporter: Daniel Bonniot <bonniot>
Component: javaAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: enhancement CC: gcc-bugs, java-prs
Priority: P3    
Version: 3.3.1   
Target Milestone: ---   
Host: i386-debian-linux-gnu Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-09-30 13:31:46

Description Daniel Bonniot 2003-08-25 23:13:46 UTC
There seems to be precision errors in the display of Float constants by jcf-dump

blanche ~/tmp/bug cat Float.java                               [01:09 26/08/03]
class Float
{
  public static void main(String[] args)
  {
    double d = 1.1;
    System.out.println(d);
  }
}
blanche ~/tmp/bug javac Float.java                             [01:09 26/08/03]
blanche ~/tmp/bug java Float                                   [01:10 26/08/03]
1.1

The problem is when disassembling the class file. javap does it correctly:
blanche ~/tmp/bug javap -c Float                               [01:10 26/08/03]
Compiled from Float.java
...
Method void main(java.lang.String[])
   0 ldc2_w #2 <Double 1.1>
...

jcf-dump writes instead:
blanche ~/tmp/bug jcf-dump-3.3 -c Float.class                  [01:10 26/08/03]
...
Method name:"main" public static Signature: 13=(java.lang.String[])void
Attribute "Code", length:44, max_stack:3, max_locals:3, code_length:12
  0: ldc2_w #2=<Double 1.1000000000000000888>
Comment 1 Andrew Pinski 2003-08-25 23:38:31 UTC
Not a bug as 1.1 cannot be be repesentive exactly in a floating point number (jcf-dump is just 
writting more precision out any way so it should not matter).
Comment 2 Tom Tromey 2003-08-25 23:56:50 UTC
I'm not certain this is not a bug.
Ideally jcf-dump would follow java rules for printing
these constants, though that might be hard to achieve.
Comment 3 Daniel Bonniot 2003-08-26 00:02:39 UTC
It was unthoughtful for me not to set severity to "enhancement" and priority to
1. Indeed, this is not a bug. I understand that 1.1000000000000000888 is the
same double as 1.1. However, I think it is much nicer to see the later than the
former (formally, nicer actually means shorter). The difference in decimal
representation lead me on a wrong track, when debuging a compiler. So it does
make a difference.
javap and dis both use the expected representation.

So I hope you won't mind that I reopen the report, now with low severity and
priority. 
Comment 4 Andrew Pinski 2003-08-26 00:04:42 UTC
P3 is the lowest, not P1.
Comment 5 Andrew Pinski 2003-11-25 07:26:35 UTC
Confirmed.