From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9642 invoked by alias); 25 Apr 2002 05:48:26 -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 9618 invoked from network); 25 Apr 2002 05:48:23 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 25 Apr 2002 05:48:23 -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 WAA08284; Wed, 24 Apr 2002 22:48:18 -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 g3P5mHX10920; Wed, 24 Apr 2002 22:48:17 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 22:48:16 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 22:48:16 -0700 Message-ID: <40700B4C02ABD5119F000090278766443BF23F@hplex1.hpl.hp.com> From: "Boehm, Hans" To: "'tromey@redhat.com'" Cc: "'java@gcc.gnu.org'" Subject: SPECjbb X86 validation failures Date: Thu, 25 Apr 2002 01:26:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2002-04/txt/msg00353.txt.bz2 I'm unfortunately still seeing problems with SPECjbb on X86 with gcc3.1. These are apparently optimization failures. They don't seem to be correlated with the reload1.c ICEs that I mentioned earlier. I know that: - They occur at -O1 and -O2, but not at -O0. - The result is incorrect code, which is detected by the SPECjbb validation test. - More than one file in SPECjbb is misoptimized as a result. - They do not occur on IA64. I've identified one file that's definitely being misoptimized (by binary search). Are there known techniques for systematically narrowing this down further? I'm looking for something like a list of optimization flags implied by -O1 that I can toggle individually, and ideally a flag to turn off optimization in all functions past line N, or something similar. The underying problem here is that this is a fairly large body of code, which I don't understand well. Thus tracking down a bug is hard, and tracking down a misoptimization is harder. Thanks. Hans