Re: java/6382: Conversion of long constants to string uses bad format

Re: java/6382: Conversion of long constants to string uses bad format

[tromey]

Synopsis: Conversion of long constants to string uses bad format

State-Changed-From-To: open->analyzed
State-Changed-By: tromey
State-Changed-When: Tue Apr 23 10:19:07 2002
State-Changed-Why:
    Alex says that print_int_node is meant to be used for error reporting only.
    So the correct fix is to replace non-error calls to it
    with calls to a new function.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6382

Re: java/6382: Conversion of long constants to string uses bad format

[tromey]

Synopsis: Conversion of long constants to string uses bad format

State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Sat Apr 27 13:32:38 2002
State-Changed-Why:
    I've checked in a fix for this.
    It will appear in gcc 3.2.
    I will probably put it into 3.1.1, assuming I remember to.
    It is too late for 3.1.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6382

Re: java/6382: Conversion of long constants to string uses bad format

[tromey]

Synopsis: Conversion of long constants to string uses bad format

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Apr 24 10:21:38 2002
Responsible-Changed-Why:
    I'm handling this.
    I've submitted a patch:
    
    http://gcc.gnu.org/ml/java-patches/2002-q2/msg00220.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6382

java/6382: Conversion of long constants to string uses bad format

[Hans_Boehm]

>Number:         6382
>Category:       java
>Synopsis:       Conversion of long constants to string uses bad format
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 19 21:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Hans_Boehm@hp.com
>Release:        GCC pre3.1
>Organization:
>Environment:
Linux/X86
>Description:
Java compiler folds conversion of long to string such that
the resulting string is in hexadecimal and unsigned.  It
should be signed and decimal.

This occurs if either a class file or object code is
generated.  It does not occur on IA64.

Discussion with Tom Tromey:

Hans> On X86, converting something like (long)1<<63 or (long)3 << 62 
  Hans> to a string results in an unsigned hexadecimal value, instead of 
  Hans> a negative decimal one, as required by the spec.  This seems to 
  Hans> be a constant folding problem: The string appears literally in 
  Hans> the gcj -C output.  Interestingly, gcj -C does the right thing 
  Hans> on IA64. 

  I tried: 

      "" + ((long) 1 << 63) 

  There's definitely a bug here. 
  And luckily the problem isn't in fold (fold is known to have problems 
  for java; fixing this is a bit involved). 

  I debugged a little.  It looks like parse.y:print_int_node is 
  incorrect.  As far as I can tell this should never decide to print a 
  number in hex (string conversion always uses decimal).  This also 
  means we can't rely on sprintf to format the number. 

  Could you submit a PR for this?  I doubt we'll fix this for 3.1 given 
  the age of the code (it predates the first public release of gcj). 
>How-To-Repeat:
Compile the following with either 

gcj -C lt.java, or
gcj --main=lt lt.java

and run it.

public class lt {
    public static void main(String argv[]) {
        System.out.println("" + ((long)1 << 63));
        System.out.println("" + ((long)3 << 62));
    }
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: