From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6598 invoked by alias); 23 Jun 2005 14:45:55 -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 6579 invoked by uid 22791); 23 Jun 2005 14:45:50 -0000 Received: from mail-out2.fuse.net (HELO smtp2.fuse.net) (216.68.8.175) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 23 Jun 2005 14:45:49 +0000 Received: from gx4.fuse.net ([216.68.17.142]) by smtp2.fuse.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050623144547.HNSU10827.smtp2.fuse.net@gx4.fuse.net> for ; Thu, 23 Jun 2005 10:45:47 -0400 Received: from dellpi.pinski.fam ([216.68.17.142]) by gx4.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20050623144547.BFKO12227.gx4.fuse.net@dellpi.pinski.fam>; Thu, 23 Jun 2005 10:45:47 -0400 Received: from [10.0.0.80] (zhivago.i.pinski.fam [10.0.0.80]) by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id j5NEjhQi025505; Thu, 23 Jun 2005 10:45:43 -0400 (EDT) In-Reply-To: <42BAC270.4010307@codesourcery.com> References: <42BAC270.4010307@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f92a838917e2f5595e5c231efd64fa5@physics.uc.edu> Content-Transfer-Encoding: 7bit Cc: gcc mailing list From: Andrew Pinski Subject: Re: GCC 4.0.1 Status Date: Thu, 23 Jun 2005 14:45:00 -0000 To: Mark Mitchell X-SW-Source: 2005-06/txt/msg00999.txt.bz2 On Jun 23, 2005, at 10:08 AM, Mark Mitchell wrote: > * PR 22043, which involves a failure to initialize fields in automatic > structures. The patch has been applied to the 4.0 branch, but the > target milestone still says 4.0.1. Bugmasters, is that just a > mistake? Yes this was a mistake. > * PR 22000, in which we throw away volatile reads. That's a serious > problem for embedded targets. And I think it is still latent on the mainline too, just harder to expose because of the changes to what passes are run and when. I found a testcase for the mainline too. > * PR 22051, which involves wrong-code generation for pointer > comparisons on one of our primary platforms. There is a missing cast which causes this but I have not looked into who is causing this, it might be fold. > * PR 21985, in which we are mis-folding expressions involving pointer > arithmetic. And this is fixed on the mainline already. -- Pinski