From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20131 invoked by alias); 14 May 2003 22:06:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 20081 invoked by uid 71); 14 May 2003 22:06:01 -0000 Date: Wed, 14 May 2003 22:06:00 -0000 Message-ID: <20030514220601.20079.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Dara Hazeghi Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail Reply-To: Dara Hazeghi X-SW-Source: 2003-05/txt/msg01712.txt.bz2 List-Id: The following reply was made to PR c++/10776; it has been noted by GNATS. From: Dara Hazeghi To: Pete Gonzalez Cc: gcc-gnats@gcc.gnu.org Subject: Re: c++/10776: [3.3 regression] Large aggregate initializers cause GCC to fail Date: Wed, 14 May 2003 15:01:45 -0700 (PDT) --- Pete Gonzalez wrote: > At 01:28 PM 5/14/2003, Dara Hazeghi wrote: > >Well thank you for the report, and the analysis. > I'm > >not certain how likely this is to get fixed in > 3.3.X, > >but it certainly doesn't hurt to have the report. > > We've worked around it. The larger cause is that, > in an aggregate > initializer, referencing an external pointer causes > a > "__static_initialization_and_destruction" function > to be generated. > GCC implements this with a bunch of assignment > instructions, and > with 2,500 entries in the array, I guess it > translates into more > code than the optimizer can handle. The general > solution would be > to replace this with a memcpy() -- maybe that's what > 3.4 does? > For my specific problem, I redesigned the data types > so that the > initialization function is not created, which is > much more efficient > in both speed and size. > > In this light, the bug becomes obscure and can > probably be closed. > My suggestion is to add some documentation > explaining the rules > behind the compiler's decision to create > initialization functions. > This is particularly important for embedded systems, > where the > initializers cause const data to end up in RAM. Well, as long as the bug is present on an active branch, I think we should keep it open. But it would definitely be good to document this behavior somewhere... Perhaps in a comment in the functions in the compiler which do this... Dara __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com