From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17360 invoked by alias); 23 Jan 2004 03:39:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17353 invoked from network); 23 Jan 2004 03:39:32 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sources.redhat.com with SMTP; 23 Jan 2004 03:39:32 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Ajs9v-0005hE-00; Thu, 22 Jan 2004 22:39:03 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id DAD244B104; Thu, 22 Jan 2004 22:38:54 -0500 (EST) To: drow@mvista.com Subject: Re: branch comparison tables Cc: gdb@sources.redhat.com Message-Id: <20040123033854.DAD244B104@berman.michael-chastain.com> Date: Fri, 23 Jan 2004 03:39:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00264.txt.bz2 > By the way, FYI: At this moment, the FAILs (only, not looking at the > kfails at the moment) for GCC 3.4 and GCC HEAD are in several > categories: Well, that's what "compare by gcc" is for. In this set of tables: http://www.shout.net/~mec/sunday/2004-01-19-branch Here are the files that have a regression from gcc 3.3.2 to gcc gcc-3_4-branch or a regression from gcc 3.3.2 to gcc HEAD, with either gdb 6.0 or gdb HEAD: gdb.base/break.exp gdb.base/scope.exp gdb.base/sepdebug.exp gdb.base/store.exp gdb.cp/anon-union.exp gdb.cp/classes.exp gdb.cp/local.exp gdb.cp/namespace.exp gdb.java/jmisc1.exp gdb.java/jmisc2.exp gdb.mi/mi-until.exp gdb.mi/mi-var-block.exp gdb.mi/mi1-until.exp gdb.mi/mi1-var-block.exp gdb.mi/mi2-until.exp gdb.mi/mi2-var-block.exp gdb.threads/tls.exp > I believe that no more of them are caused by GCC. PR gcc/12267 is still causing stabs problems. gdb.cp/anon-union.exp is blowing up, I haven't analyzed it yet. > The multi_line_while_statement failures in your tables were, but I > checked in a fix this morning. That will show up in my next spin, 36-48 hours from now. Michael C