From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-17549-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12236 invoked by alias); 20 Apr 2002 04:06:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 12207 invoked by uid 71); 20 Apr 2002 04:06:00 -0000
Resent-Date: 20 Apr 2002 04:06:00 -0000
Resent-Message-ID: <20020420040600.12205.qmail@sources.redhat.com>
Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
Resent-To: nobody@gcc.gnu.org
Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, java-prs@gcc.gnu.org,
  tromey@redhat.com
Resent-Reply-To: gcc-gnats@gcc.gnu.org, Hans_Boehm@hp.com
Received:(qmail 11739 invoked by uid 61); 20 Apr 2002 04:01:41 -0000
Message-Id:<20020420040141.11737.qmail@sources.redhat.com>
Date: Fri, 19 Apr 2002 21:06:00 -0000
From: Hans_Boehm@hp.com
Reply-To: Hans_Boehm@hp.com
To: gcc-gnats@gcc.gnu.org
Cc: tromey@redhat.com
X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31)
X-GNATS-Notify:tromey@redhat.com
Subject: java/6382: Conversion of long constants to string uses bad format
X-SW-Source: 2002-04/txt/msg01012.txt.bz2
List-Id: <gcc-prs.sourceware.org>


>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: