From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10235 invoked by alias); 16 Oct 2002 18:30:02 -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 10193 invoked from network); 16 Oct 2002 18:30:00 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 16 Oct 2002 18:30:00 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g9GIRmW01865; Wed, 16 Oct 2002 11:27:48 -0700 Date: Wed, 16 Oct 2002 13:02:00 -0000 From: Mark Mitchell To: Nathan Sidwell cc: "gcc@gcc.gnu.org" , "aoliva@redhat.com" , "jason@redhat.com" Subject: Re: PR 8134: C++ crash Message-ID: <324520000.1034792868@warlock.codesourcery.com> In-Reply-To: <3DAC62E6.4030002@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-10/txt/msg00983.txt.bz2 --On Tuesday, October 15, 2002 07:48:06 PM +0100 Nathan Sidwell wrote: > Mark Mitchell wrote: >> PR 8134 is a crash in force_store_init_value on the branch; it is a >> regression. > >> a) Nothing >> b) Move my changes over. >> c) Revert Alexandre's patch. Jason wishes there was another choice, but thus far hasn't been able to come up with one. Gaby and Benjamin think that my large patch is bug-free. Nathan isn't so optimistic. I'm not so optimistic either. I know my new patch is right in concept, but I'm not sure it's bugless. I don't think it's prudent to move over a patch that substantial when it hasn't received more than a week or two of testing. So, I'm going to go with (c). I'll be updating the caveats HTML page with information about this. The good news is that pointers-to-members are rare, programs relying on zero-initialization of them are rarer, and there is always a work-around -- explicitly initialize the pointer-to-member. I hope people use pointers-to-members a lot on IPF. The whole deal here is that we're trying to save an addition per use of a pointer to data member on a machine that doesn't have base+offset addressing. I have this bad feeling that I've spent more time implementing this stuff than will ever be saved by all the programs in the world running for all time on architectures where this will help...) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com