From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7074 invoked by alias); 26 Apr 2002 21:42:11 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 7060 invoked from network); 26 Apr 2002 21:42:08 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 26 Apr 2002 21:42:08 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id OAA29961; Fri, 26 Apr 2002 14:42:07 -0700 (PDT) Received: from hplex1.hpl.hp.com (hplex1.hpl.hp.com [15.0.152.182]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with SMTP id g3QLg6j04432; Fri, 26 Apr 2002 14:42:06 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Fri, 26 Apr 2002 14:42:05 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 14:42:05 -0700 Message-ID: <40700B4C02ABD5119F000090278766443BF24E@hplex1.hpl.hp.com> From: "Boehm, Hans" To: "'java@gcc.gnu.org'" Cc: "'tromey@redhat.com'" Subject: SPECjbb vs. 3.1 status Date: Fri, 26 Apr 2002 15:48:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-04/txt/msg00381.txt.bz2 I think I now understand all the issues still affecting SPECjbb and gcc3.1 on X86 (IA64 is fine): 0) GNATS 6411 and 6382 force some of the sanity tests to be commented out. 1) The ICEs at reload1.c:9514 reported in http://gcc.gnu.org/ml/java/2002-04/msg00253.html are still there. For 3.1 only, should we replace the offending "abort();" by a "continue;"? This seems to work around the problem, at least for examples similar to the ones I've seen. I have mixed feelings about it, since I'm not sure how likely it is to turn an ICE into silentely emitted wrong code. 2) Floating point operations are generally carried out at the wrong precision on X86. AFAICT, the fp control word specifies extended precision operation, but the JLS requires that we never use more than double precision (though we may use bigger exponents if strictfp isn't specified). This causes the following program to print 8 instead of 9. (I claim that if you write this code, you have no real reason to expect either answer. Double precision happens to work out such that you get the more intuitive answer. Extended precision doesn't, particularly since the constant is only generated at double precision.) Unless there is a really easy way to fix this, I think this will have to wait for a later release. I'm not sure what the intended conventions are about the control word. Test case: public class fp_test { private int m; private int n; fp_test(int k) { if (k < 5) { m = 30; } else { m = 0; } n = (short)(m * 0.30); } public static void main(String argv[]) { fp_test fpt = new fp_test(0); System.out.println(fpt.n); } } This affects SPECjbb in that a random number generator may be invoked the wrong number of times, thus causing the results to vary. It also turns out it tickles what I think is a bug in the source. (The bug doesn't affect the utility of the benchmark. But it seems to magnify rounding errors in unintended ways.) Hans