From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25757 invoked by alias); 31 Jan 2003 01:27:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25750 invoked from network); 31 Jan 2003 01:27:34 -0000 Received: from unknown (HELO tigers-lfs.local) (144.132.162.109) by 172.16.49.205 with SMTP; 31 Jan 2003 01:27:34 -0000 Received: from gws by tigers-lfs.local with local (Exim 4.10) id 18ePyc-00068c-00; Fri, 31 Jan 2003 12:28:18 +1100 Date: Fri, 31 Jan 2003 02:14:00 -0000 From: Greg Schafer To: Gabriel Dos Reis Cc: Joe Buck , Paolo Carlini , gcc@gcc.gnu.org Subject: Re: GCC-3.2.2 pre-release (second iteration) Message-ID: <20030131012818.GA23579@tigers-lfs.nsw.bigpond.net.au> References: <15927.61897.77306.255799@gauvain.inria.fr> <20030129135455.A10912@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-01/txt/msg01719.txt.bz2 On Fri, Jan 31, 2003 at 01:22:31AM +0100, Gabriel Dos Reis wrote: > I'm also seeing those failures with the tarball I uploaded but not > on current version of gcc-3_2-branch (which will be the next > iteration). > > I looked into the failures and cannot find out which patches could > have possibly caused those failures. All failures seem to be > "syntax error". I'm inclined to conlude that the environment I used > to prepare the second iteration (which is at work) might be insane [it > is the one which started the reduce/reduce conflit thread]. > > I would like you run the testsuite again but for current CVS > gcc-3_2-branch and report the results. Thank you very much for your > time. Gabriel, just a heads up. the tarball does indeed appear to be broken. Building from the tarball shows the failures whereas building from CVS is fine for me:- tarball: http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01382.html CVS: http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01325.html It is probably the bison thing as Paolo suggested. But I thought the maintainer scripts were supposed to adjust the timestamps so as not to rely on the bison in the user's environment. Dunno. Greg